Dirty Frag (CVE-2026-43284) — PoC de Escape de Contêiner Kubernetes

Uma prova de conceito demonstrando como um Pod Kubernetes padrão, sem privilégios pode alcançar execução de código em nível de nó no Amazon EKS ao explorar a vulnerabilidade de corrupção do page-cache do kernel Linux Dirty Frag por meio de camadas de imagem de contêiner compartilhadas.

O primitivo 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. Este PoC usa o kube-proxy como um exemplo concreto, mas a técnica se generaliza para qualquer workload privilegiado no cluster.

Validado no Amazon EKS (kernel 6.12.80) — um pod sem privilégios escreve [*] success no sistema de arquivos do host por meio do DaemonSet privilegiado kube-proxy:

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

Contexto

Dirty Frag (CVE-2026-43284) é uma vulnerabilidade de corrupção do page-cache do kernel Linux no caminho de recepção xfrm/ESP. No caminho afetado, esp_input() pode pular skb_cow_data() para um skb não linear sem frag_list, permitindo que crypto_authenc_esn_decrypt() armazene 4 bytes de dados controlados pelo atacante em uma página do page-cache alcançada por meio de splice().

O arquivo no disco não é modificado. Os bytes corrompidos residem no page-cache do kernel e são observados por leitores posteriores da mesma página de arquivo em cache.

Para detalhes completos sobre a vulnerabilidade original, consulte V4bel/dirtyfrag.

Princípio do Ataque

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

1. Corrupção do page-cache do kernel (CVE-2026-43284) — um processo sem privilégios (com suporte a user namespaces) pode sobrescrever as páginas em cache na memória de qualquer arquivo que possa abrir somente para leitura, por meio da corrida xfrm/ESP splice.
2. Compartilhamento de camadas de imagem — runtimes de contêiner (containerd, CRI-O) usam filesystems overlay onde camadas de imagem idênticas mapeiam para as mesmas páginas do page-cache entre contêineres.
3. DaemonSets privilegiados — muitos clusters executam DaemonSets com privilégios elevados (privileged: true, hostNetwork: true, capabilities amplas, etc.) que executam periodicamente binários de suas imagens.

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

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

Diferença do Copy Fail

Este projeto é inspirado no modelo de exploração Kubernetes documentado no Copy Fail Kubernetes PoC, mas usa um primitivo de kernel diferente.

Como Funciona

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

1. Patch do Page-Cache via xfrm/ESP

O binário do PoC executa a seguinte sequência a partir de um contêiner sem privilégios:

1. Entra em novos user e network namespaces com unshare(CLONE_NEWUSER | CLONE_NEWNET).
2. Registra muitas Security Associations xfrm cujos campos de sequência alta codificam blocos de payload de 4 bytes.
3. Abre um binário alvo da camada de imagem compartilhada somente para leitura.
4. Usa splice() e entrada ESP elaborada para acionar o caminho vulnerável do kernel.
5. Repete o primitivo até que o conteúdo do page-cache do binário alvo contenha o payload embutido.

Nenhuma permissão de escrita no arquivo alvo é necessária. O arquivo no disco permanece inalterado — apenas o page-cache na memória é corrompido.

2. Propagação entre Contêineres via Camadas Compartilhadas

Os runtimes de contêiner atendem leituras das camadas inferiores do overlay por meio do page-cache do kernel. Se o contêiner do PoC e o kube-proxy compartilham o mesmo arquivo de camada inferior, ambos observam as mesmas páginas em cache.

A imagem EKS neste repositório é construída a partir de:

public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables:2026-03-11-1773190710.2023

Essa base é escolhida para corresponder à camada da toolchain userspace do kube-proxy EKS usada no ambiente validado.

3. Execução Privilegiada pelo kube-proxy

Quando o kube-proxy executa em seguida um binário da família iptables com patch, o kernel carrega as páginas em cache corrompidas. O payload do PoC monta o dispositivo raiz do host e escreve um arquivo marcador em /root/res.

O conteúdo esperado do marcador é:

[*] success

Diagrama do Fluxo de Ataque

┌──────────────────────────────┐     ┌────────────────────────┐     ┌──────────────────────────┐
│  Pod PoC                     │     │  Page Cache do Kernel  │     │  DaemonSet kube-proxy    │
│  contêiner sem privilégios   │     │                        │     │  contêiner privilegiado  │
│                              │     │                        │     │                          │
│  1. unshare user+net ns      │     │                        │     │                          │
│  2. instalar SAs xfrm        │     │                        │     │                          │
│  3. splice do binário alvo   │────▶│  binário de camada     │────▶│  executa binário com    │
│     pelo caminho ESP         │     │  compartilhada com     │     │  patch; payload roda    │
│                              │     │  page cache alterado   │     │  com privilégios de nó  │
└──────────────────────────────┘     └────────────────────────┘     └──────────────────────────┘

Ambiente Validado

Amazon EKS

GKE e ACK — Testados, Não Exploráveis com Configuração Padrão

Testei em clusters GKE e ACK. Todos falharam.

O primitivo Dirty Frag requer criação de user namespace (CLONE_NEWUSER) para obter CAP_NET_ADMIN dentro de um novo network namespace. Tanto ACK quanto GKE bloqueiam isso no nível do nó por meio de mecanismos diferentes:

• ACK: Restrição em nível de kernel (user.max_user_namespaces=0) impede completamente a criação de user namespaces sem privilégios.
• GKE: O perfil seccomp padrão (habilitado pela flag --seccomp-default do kubelet) bloqueia a syscall unshare independentemente do limite de namespaces.

Esta é uma diferença fundamental do Copy Fail (CVE-2026-31431), que não requer user namespaces e explora com sucesso todas as três plataformas.

kube-proxy como Exemplo Concreto

A variante EKS fornecida aplica patch nos seguintes binários quando presentes:

/usr/sbin/xtables-legacy-multi
/usr/sbin/xtables-nft-multi

Esses binários são invocados pela toolchain iptables usada pelo kube-proxy. O momento exato do acionamento depende da reconciliação de nós e serviços. No ambiente validado, o payload foi acionado pela reconciliação normal do kube-proxy.

Avisos importantes:

• O kube-proxy só invoca ipset quando configurado no modo ipvs. O modo padrão (iptables) não usa ipset.
• Algumas distribuições Kubernetes gerenciadas executam o kube-proxy como um contêiner não privilegiado, o que limita o impacto do escape.
• O PoC tem como alvo vários binários (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 mantém — você só precisa identificar um DaemonSet privilegiado diferente que compartilhe camadas de imagem com uma imagem base a partir da qual você possa construir.

Estrutura do Repositório

.
├── exploit/
│   └── dirtyfrag.c              # Escritor do page-cache xfrm/ESP
├── payload/
│   ├── payload-eks.c            # Payload nolibc que escreve /root/res no host
│   └── nolibc/                  # Cabeçalhos Linux nolibc
├── deploy/
│   └── poc-eks.yaml             # Manifesto de Deployment EKS sem privilégios
├── scripts/
│   ├── setup-eks.sh             # copia, compila e importa imagem em um nó EKS
│   ├── run-poc.sh               # implanta e verifica o marcador
│   └── cleanup.sh              # remove pod, marcador, páginas em cache e imagem local
├── Dockerfile.eks               # Imagem EKS baseada em eks-distro-minimal-base-iptables
├── Makefile                     # alvos de build para payload, exploit, Docker e nerdctl
└── .github/workflows/
    └── docker-publish.yml       # Workflow de publicação GHCR

Compilação e Uso

# Compilar payload + binário do exploit
make build-eks CC=x86_64-linux-gnu-gcc

# Compilar imagem Docker
make docker-build-eks

# Implantar (pod sem privilégios)
kubectl apply -f deploy/poc-eks.yaml

# Verificar logs
kubectl logs deployment/dirtyfrag-poc-eks

# Verificar escape no nó
ssh ec2-user@<node-ip> "sudo cat /root/res"
# Esperado: [*] success

O workflow do GitHub Actions (.github/workflows/docker-publish.yml) publica a imagem no GHCR ao fazer push para main ou criação de tag. Substitua <owner> em deploy/poc-eks.yaml pelo usuário ou organização do GitHub que possui o fork.

Limpeza

kubectl delete -f deploy/poc-eks.yaml --ignore-not-found
ssh ec2-user@<node-ip> "sudo rm -f /root/res"
kubectl delete pod -n kube-system -l k8s-app=kube-proxy --force

Versões Afetadas

• Kernel Linux: Todas as versões anteriores ao patch do CVE-2026-43284 (commit f4c50a4034e6).
• Kubernetes: Qualquer versão que use um kernel de nó sem patch com user namespaces habilitados. 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 page-cache para escape completo de contêiner.

Mitigação

• Aplique o patch no kernel. Atualize para um kernel que contenha a correção do Dirty Frag, incluindo o commit f4c50a4034e6 ou o backport do fornecedor.
• Desabilite módulos ESP não utilizados. Bloqueie esp4 e esp6 se IPsec ESP não for necessário nos nós de trabalho.
• Restrinja user namespaces. Definir user.max_user_namespaces=0 impede que este PoC obtenha CAP_NET_ADMIN em um novo network namespace (isso já é o padrão no ACK).
• Use perfis seccomp restritivos. RuntimeDefault ou perfis personalizados podem bloquear syscalls-chave de namespace e rede (isso já é o padrão no GKE).
• Minimize DaemonSets privilegiados. Evite privileged: true e acesso amplo ao host, a menos que estritamente necessário.
• Reduza o compartilhamento de camadas com workloads privilegiados. Use imagens base distintas para agentes privilegiados e controle onde workloads não confiáveis podem ser executados.

Exemplo de bloco de módulo:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
sudo rmmod esp4 esp6 2>/dev/null || true

Créditos

• Pesquisa do Dirty Frag e exploit original: V4bel/dirtyfrag

Referências

• Dirty Frag - V4bel/dirtyfrag
• Cobertura do LWN
• Discussão do CVE-2026-43284 xfrm/ESP
• Copy Fail Kubernetes PoC

Licença

O código do exploit é adaptado de V4bel/dirtyfrag sob a licença MIT.

O código do payload é derivado de tgies/copy-fail-c e é dual-licenciado sob LGPL-2.1-or-later OU MIT.

Os cabeçalhos nolibc são da infraestrutura de self-test do kernel Linux.