Copy Fail (CVE-2026-31431) — Prova de Conceito de Escape de Contêiner Kubernetes

Uma prova de conceito demonstrando como um contêiner totalmente não privilegiado pode alcançar execução de código no nível do nó no Kubernetes explorando o bug de corrupção do cache de páginas do kernel Linux CVE-2026-31431 através de camadas de imagem de contêiner compartilhadas.

A primitiva de ataque central é: qualquer DaemonSet privilegiado que compartilhe camadas de imagem com um contêiner controlado pelo atacante pode ser transformado em arma para escape de contêiner. Esta PoC usa kube-proxy como um exemplo concreto, mas a técnica se generaliza para qualquer carga de trabalho privilegiada no cluster.

Validado em Alibaba Cloud ACK, Amazon EKS e Google GKE — um pod não privilegiado escreve [*] success no sistema de arquivos do host através do DaemonSet privilegiado kube-proxy:

Alibaba Cloud ACK (kernel 6.6.88)	Amazon EKS (kernel 6.12.79)	Google GKE (kernel 6.12.68)

Aviso: Este repositório é publicado apenas para fins educacionais e de defesa. Use-o exclusivamente em sistemas que você possui ou possui autorização explícita para testar.

Histórico

CVE-2026-31431 ("Copy Fail") é uma vulnerabilidade do kernel Linux no caminho de Copy-on-Write (CoW) do cache de páginas. Uma condição de corrida com AF_ALG splice permite que um processo não privilegiado corrompa as páginas do cache de páginas de um arquivo somente leitura. A corrupção persiste no cache de páginas do kernel e é visível para todos os processos que posteriormente leem ou executam o arquivo — incluindo processos em outros contêineres ou no host.

Para detalhes completos sobre a vulnerabilidade original, veja copy.fail.

Princípio do Ataque

O ataque explora três propriedades que comumente coexistem em clusters Kubernetes:

1. Corrupção do cache de páginas do kernel (CVE-2026-31431) — um processo não privilegiado pode sobrescrever as páginas em cache na memória de qualquer arquivo que possa abrir como somente leitura.
2. Compartilhamento de camadas de imagem — os runtimes de contêiner (containerd, CRI-O) usam sistemas de arquivos overlay onde camadas de imagem idênticas mapeiam para as mesmas páginas do cache de páginas entre contêineres.
3. DaemonSets privilegiados — muitos clusters executam DaemonSets com privilégios elevados (privileged: true, hostNetwork: true, capacidades amplas, etc.) que executam periodicamente binários de sua imagem.

Quando essas condições se alinham, um pod não privilegiado pode corromper um binário em uma camada de imagem compartilhada, e um DaemonSets privilegiado no mesmo nó executará inconscientemente o binário corrompido com seus privilégios elevados — alcançando execução de código no nível do nó.

O alvo da vulnerabilidade NÃO se limita ao kube-proxy. Qualquer DaemonSets privilegiado (agentes de monitoramento, plugins CNI, coletores de log, agentes de segurança, etc.) cuja imagem de contêiner compartilhe camadas com uma imagem controlada pelo atacante é um alvo viável.

Como Funciona

A cadeia de ataque tem três estágios: corrupção do cache de páginas, propagação entre contêineres e execução privilegiada.

1. Corrupção do Cache de Páginas via Corrida de Splice AF_ALG

O subsistema AF_ALG (criptografia) do kernel expõe uma interface baseada em socket para operações criptográficas do espaço do usuário. O exploit abusa de uma condição de corrida em como o kernel lida com splice() de um arquivo em um socket AF_ALG:

1. Abra o binário alvo como somente leitura.
2. Crie um socket AF_ALG AEAD vinculado a authencesn(hmac(sha256),cbc(aes)).
3. Envie um pequeno pedaço de carga útil através do socket AF_ALG com MSG_MORE, informando ao kernel que mais dados virão.
4. Use splice() para transferir o conteúdo do arquivo alvo de um fd → pipe → socket AF_ALG.
5. Devido ao bug de CoW, o kernel escreve os bytes da carga útil do atacante nas páginas do cache de páginas do arquivo alvo em vez de isolá-los adequadamente.

O exploit repete isso para cada janela de 4 bytes até que todas as páginas em cache do binário alvo sejam sobrescritas com uma carga útil personalizada.

Nenhuma permissão de escrita no arquivo é necessária. O arquivo no disco não é alterado — apenas o cache de páginas na memória é corrompido.

2. Propagação entre Contêineres via Compartilhamento de Camadas de Imagem

Os runtimes de contêiner usam sistemas de arquivos overlay. Quando dois contêineres compartilham a mesma camada de imagem, o kernel serve as leituras de arquivos a partir das mesmas páginas do cache de páginas.

O atacante constrói sua imagem PoC FROM a mesma imagem base do DaemonSets privilegiado alvo. Como ambos os contêineres compartilham o mesmo diretório inferior overlay, binários na camada compartilhada mapeiam para páginas do cache de páginas idênticas.

Quando o contêiner PoC não privilegiado corrompe o cache de páginas de um binário, a corrupção é imediatamente visível para o contêiner privilegiado no mesmo nó — com zero comunicação entre contêineres.

3. Execução Privilegiada pelo DaemonSets Alvo

Quando o DaemonSets privilegiado executa qualquer binário corrompido (através do seu ciclo normal de operação), o kernel carrega as páginas corrompidas do cache de páginas. A carga útil do atacante é executada com todos os privilégios do DaemonSets — potencialmente incluindo:

• Root completo no nó
• Todas as capacidades
• Acesso aos namespaces do host (rede, PID, montagem)

A carga útil nesta PoC (payload/payload.c) simplesmente monta o sistema de arquivos raiz do host e escreve um arquivo marcador em /root/res como prova de execução de código no nível do nó.

Diagrama do Fluxo de Ataque

┌──────────────────────────┐     ┌──────────────────────────┐
│   Contêiner PoC          │     │   DaemonSets Privilegiado│
│   (não privilegiado)     │     │   (ex.: kube-proxy,      │
│                          │     │    agente de monitora.)  │
│  1. Abre binário alvo    │     │                          │
│     (somente leitura)    │     │                          │
│                          │     │                          │
│  2. Corrida splice AF_ALG│     │                          │
│     corrompe cache de    │     │                          │
│     páginas              │     │                          │
│          │               │     │                          │
└──────────┼───────────────┘     └──────────────────────────┘
           │                                  │
           ▼                                  │
  ┌─────────────────────┐                     │
  │  Cache de Páginas    │                     │
  │  do Kernel           │                     │
  │                      │◄────────────────────┘
  │  Binário da camada   │     3. DaemonSets executa o
  │  compartilhada       │        binário corrompido
  │  (CORROMPIDO)        │        → carrega páginas
  │  contém bytes da     │           corrompidas
  │  carga útil do       │        → carga útil executa com
  │  atacante            │           privilégios do DaemonSets
  └─────────────────────┘

Ambientes de Nuvem Validados

A PoC foi validada com sucesso nas seguintes plataformas Kubernetes gerenciadas:

Alibaba Cloud ACK

Amazon EKS

Google GKE

Em todos os três casos, um pod PoC não privilegiado escreveu com sucesso o arquivo marcador [*] success no sistema de arquivos do host — provando execução de código no nível do nó através do DaemonSets privilegiado kube-proxy.

Para os guias completos (análise de camada de imagem, passos de construção, implantação):

• EKS: docs/eks-poc.md
• GKE: docs/gke-poc.md

kube-proxy como Exemplo Concreto

Esta PoC usa kube-proxy como alvo porque é um dos DaemonSets privilegiados mais comuns em clusters Kubernetes. Três variantes são fornecidas:

• Padrão (ACK / upstream): construído FROM registry.k8s.io/kube-proxy:v1.35.2 (veja Dockerfile)
• EKS: construído FROM public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables:2026-03-11-1773190710.2023 (veja Dockerfile.eks)
• GKE: construído FROM us-central1-artifactregistry.gcr.io/gke-release/gke-release/kube-proxy:v1.35.3-gke.1234000 (veja Dockerfile.gke)

Todas as variantes corrompem binários como /usr/sbin/ipset, /usr/sbin/nft, /usr/sbin/xtables-legacy-multi e /usr/sbin/xtables-nft-multi.

Observações importantes:

• kube-proxy invoca ipset apenas quando configurado no modo ipvs. O modo padrão (iptables) não usa ipset. Veja kubernetes/enhancements#5495 para o plano de depreciação do ipvs.
• Algumas distribuições Kubernetes gerenciadas (ex.: certos provedores de nuvem) executam kube-proxy como um contêiner não privilegiado, o que limita o impacto do escape.
• A PoC atinge vários binários (ipset, nft, xtables-legacy-multi, xtables-nft-multi) para cobrir diferentes modos de proxy, mas se eles serão invocados depende da configuração do cluster.

Se o kube-proxy não for privilegiado no seu cluster, o princípio do ataque ainda se aplica — você só precisa identificar um DaemonSets privilegiado diferente que compartilhe camadas de imagem com uma imagem base que você possa construir.

Generalizando para Outros Alvos

Para adaptar esta PoC a um DaemonSets privilegiado diferente:

1. Identifique um DaemonSets privilegiado em execução no cluster (agentes de monitoramento, plugins CNI, coletores de log, etc.).
2. Construa sua imagem PoC FROM a mesma imagem base usada por aquele DaemonSets.
3. Identifique binários na camada compartilhada que o DaemonSets executará durante sua operação normal.
4. Corrompa o cache de páginas desses binários usando o exploit.

Estrutura do Repositório

.
├── cmd/copyfail/main.go          # Ponto de entrada; incorpora a carga útil compilada
├── internal/
│   ├── exploit/
│   │   ├── exploit.go            # Exploit principal: loop de corrida AF_ALG splice
│   │   └── patch.go              # Divide a carga útil em janelas de patch de 4 bytes
│   └── alg/
│       └── alg.go                # Abstração de socket AF_ALG AEAD
├── payload/
│   ├── payload.c                 # Carga útil ACK/upstream (monta /dev/vda3 ext4)
│   ├── payload-eks.c             # Carga útil EKS (detecção automática de dispositivo NVMe/Xen)
│   ├── payload-gke.c             # Carga útil GKE (detecção automática de dispositivo COS/Ubuntu)
│   └── nolibc/                   # libc mínima do kernel para payloads estáticos sem dependências
├── deploy/
│   ├── poc.yaml                  # Manifesto de Deployment Kubernetes (ACK/upstream)
│   ├── poc-eks.yaml              # Manifesto de Deployment EKS
│   └── poc-gke.yaml              # Manifesto de Deployment GKE
├── Dockerfile                    # ACK/upstream: FROM registry.k8s.io/kube-proxy
├── Dockerfile.eks                # EKS: FROM eks-distro-minimal-base-iptables
├── Dockerfile.gke                # GKE: FROM gke-release/kube-proxy
├── Makefile                      # Orquestração de build (inclui alvos *-eks e *-gke)
└── docs/
    ├── eks-poc.md                # Guia completo da PoC EKS
    ├── gke-poc.md                # Guia completo da PoC GKE
    ├── ack-poc-res.png           # Captura de tela de validação ACK
    ├── eks-poc-res.png           # Captura de tela de validação EKS
    └── gke-poc-res.png           # Captura de tela de validação GKE

Pré-requisitos

• Go 1.25+
• Um compilador cruzado para a carga útil nolibc (padrão: x86_64-linux-gnu-gcc)
• Docker / Buildx
• Um cluster Kubernetes com um DaemonSets privilegiado que compartilhe camadas de imagem com a imagem PoC (o exemplo padrão tem como alvo kube-proxy)
• imagePullPolicy: IfNotPresent no DaemonSets alvo (o padrão do Kubernetes)
• Kernel Linux anterior à correção do CVE-2026-31431

Construindo

ACK / Upstream Kubernetes

# Compilar carga útil + binário Go
make build

# Construir imagem Docker
make docker-build

# Construir e enviar para GHCR
make docker-push IMAGE=ghcr.io/<voce>/copy-fail-poc TAG=latest

Amazon EKS

# Compilar carga útil EKS + binário Go + imagem Docker
make docker-build-eks

# Construir e enviar para GHCR
make docker-push-eks IMAGE=ghcr.io/<voce>/copy-fail-poc

Para alvos arm64 (Graviton):

make build-eks CC=aarch64-linux-gnu-gcc GOARCH=arm64

Google GKE

# Compilar carga útil GKE + binário Go + imagem Docker
make docker-build-gke

# Construir e enviar para GHCR
make docker-push-gke IMAGE=ghcr.io/<voce>/copy-fail-poc

Para nós arm64:

make docker-build-gke CC=aarch64-linux-gnu-gcc GOARCH=arm64 PLATFORM=linux/arm64

Uso

Implantar a PoC

# ACK / upstream Kubernetes
kubectl apply -f deploy/poc.yaml

# Amazon EKS
kubectl apply -f deploy/poc-eks.yaml

# Google GKE
kubectl apply -f deploy/poc-gke.yaml

O Deployment cria um único pod não privilegiado. Ele:

1. Executa /bin/copyfail para corromper o cache de páginas dos binários alvo na camada de imagem compartilhada.
2. Dorme indefinidamente para que o pod permaneça em execução para observação.

Verificar o Escape

Após o DaemonSets privilegiado alvo executar um binário corrompido (para kube-proxy, isso normalmente acontece em segundos devido ao seu loop de reconciliação), verifique o nó:

# SSH no nó, ou use um pod de depuração privilegiado

# ACK / EKS (sistema de arquivos raiz gravável)
cat /root/res
# Saída esperada: [*] success

# Nós COS do GKE (raiz somente leitura, partição stateful gravável)
cat /mnt/stateful_partition/copyfail-res
# Saída esperada: [*] success

A presença do arquivo marcador no sistema de arquivos do host prova que o código fornecido pelo atacante foi executado com privilégios de nível de nó — a partir do contexto do contêiner do DaemonSets privilegiado.

Limpeza

kubectl delete -f deploy/poc.yaml      # ou poc-eks.yaml / poc-gke.yaml

# No(s) nó(s) afetado(s), remova o marcador e reinicie o DaemonSets alvo:
rm -f /root/res                                     # ACK / EKS
rm -f /copyfail-res /mnt/stateful_partition/copyfail-res  # Nós COS GKE
# Para kube-proxy: delete o pod para forçar a releitura da camada de imagem
kubectl delete pod -n kube-system -l k8s-app=kube-proxy --field-selector spec.nodeName=<nó>

Personalizando a Carga Útil

A carga útil padrão (payload/payload.c) é um programa apenas de validação que escreve um arquivo marcador. Para construir uma carga útil personalizada:

1. Edite payload/payload.c. O programa é compilado contra nolibc (a biblioteca C mínima do kernel) para um binário estático e sem dependências.
2. Execute make payload para compilar cruzadamente.
3. A carga útil compilada é incorporada no binário Go via //go:embed.

Versões Afetadas

• Kernel Linux: Todas as versões anteriores ao patch do CVE-2026-31431.
• Kubernetes: Qualquer versão que use um kernel de nó sem patch. A vulnerabilidade está no kernel, não no Kubernetes em si. O Kubernetes apenas fornece o contexto de execução (camadas de imagem compartilhadas + DaemonSets privilegiados) que eleva o impacto de corrupção local do cache de páginas para escape completo de contêiner.

Mitigação

• Atualize o kernel. Esta é a correção definitiva.
• Ative o isolamento de camadas de imagem. Alguns runtimes suportam snapshots do sistema de arquivos por contêiner que impedem o compartilhamento do cache de páginas.
• Minimize DaemonSets privilegiados. Reduza o número de cargas de trabalho executadas com privilégios elevados; use o princípio do menor privilégio.
• Remova capacidades desnecessárias de DaemonSets que não exijam estritamente privileged: true.
• Restrinja o agendamento de pods para evitar que cargas de trabalho não confiáveis sejam colocadas em nós executando DaemonSets privilegiados com imagens base compartilhadas.
• Use imagens base distintas para cargas de trabalho privilegiadas para reduzir a chance de compartilhamento de camadas com contêineres não confiáveis.

Exemplos de Mitigação

• Regra de mitigação incorporada no vArmor: copy-fail-mitigation bloqueia o vetor de exploit impedindo que contêineres criem sockets AF_ALG. A regra está disponível através dos enforcers AppArmor e BPF.
• Mitigação Kubernetes com eBPF: iwanhae/copyfail-ebpf-k8s fornece um exemplo de mitigação Kubernetes baseada em eBPF para CVE-2026-31431.

Créditos

• Descoberta e divulgação do CVE-2026-31431: Theori / Xint
• Carga útil C multiplataforma: Tony Gies (LGPL-2.1-or-later OU MIT)
• nolibc: Testes de auto-teste do kernel Linux (tools/include/nolibc/)

Licença

O código Go do exploit neste repositório é fornecido como está para fins de pesquisa.

A carga útil (payload/payload.c) é derivada de copy-fail-c e é duplamente licenciada sob LGPL-2.1-or-later OU MIT. Veja LICENSE-LGPL e LICENSE-MIT.