Dirty Frag (CVE-2026-43284) — PoC di Container Escape Kubernetes

Una proof-of-concept che dimostra come un Pod Kubernetes predefinito e non privilegiato possa ottenere esecuzione di codice a livello di nodo su Amazon EKS sfruttando la vulnerabilità di corruzione della page cache del kernel Linux Dirty Frag tramite livelli di immagine container condivisi.

Il primitivo di attacco principale è: qualsiasi DaemonSet privilegiato che condivide livelli di immagine con un container controllato dall'attaccante può essere armato per il container escape. Questo PoC usa kube-proxy come esempio concreto, ma la tecnica si generalizza a qualsiasi workload privilegiato sul cluster.

Validato su Amazon EKS (kernel 6.12.80) — un pod non privilegiato scrive [*] success nel filesystem dell'host tramite il DaemonSet privilegiato kube-proxy:

Disclaimer: Questo repository è pubblicato esclusivamente a scopo educativo e difensivo. Usalo solo su sistemi di tua proprietà o per i quali hai esplicita autorizzazione al test.

Contesto

Dirty Frag (CVE-2026-43284) è una vulnerabilità di corruzione della page cache del kernel Linux nel percorso di ricezione xfrm/ESP. Nel percorso interessato, esp_input() può saltare skb_cow_data() per uno skb non lineare senza frag_list, consentendo a crypto_authenc_esn_decrypt() di memorizzare 4 byte di dati controllati dall'attaccante in una pagina della page cache raggiunta tramite splice().

Il file su disco non viene modificato. I byte corrotti risiedono nella page cache del kernel e vengono osservati dai successivi lettori della stessa pagina di file in cache.

Per tutti i dettagli sulla vulnerabilità originale, vedi V4bel/dirtyfrag.

Principio di Attacco

L'attacco sfrutta tre proprietà che coesistono comunemente nei cluster Kubernetes:

1. Corruzione della page cache del kernel (CVE-2026-43284) — un processo non privilegiato (con supporto user namespace) può sovrascrivere le pagine in cache in memoria di qualsiasi file che può aprire in sola lettura, tramite la race di splice xfrm/ESP.
2. Condivisione dei livelli di immagine — i runtime container (containerd, CRI-O) usano filesystem overlay in cui livelli di immagine identici mappano alle stesse pagine della page cache tra container.
3. DaemonSet privilegiati — molti cluster eseguono DaemonSet con privilegi elevati (privileged: true, hostNetwork: true, ampie capability, ecc.) che eseguono periodicamente binari dalla propria immagine.

Quando queste condizioni si allineano, un pod non privilegiato può corrompere un binario in un livello di immagine condiviso, e un DaemonSet privilegiato sullo stesso nodo eseguirà inconsapevolmente il binario corrotto con i suoi privilegi elevati — ottenendo piena esecuzione di codice a livello di nodo.

Il target della vulnerabilità NON è limitato a kube-proxy. Qualsiasi DaemonSet privilegiato (agenti di monitoraggio, plugin CNI, collector di log, agenti di sicurezza, ecc.) la cui immagine container condivide livelli con un'immagine controllata dall'attaccante è un target valido.

Differenza da Copy Fail

Questo progetto è ispirato al modello di sfruttamento Kubernetes documentato nel Copy Fail Kubernetes PoC, ma usa un primitivo del kernel diverso.

Come Funziona

La catena di attacco ha tre fasi: corruzione della page cache, propagazione tra container ed esecuzione privilegiata.

1. Patch della Page Cache tramite xfrm/ESP

Il binario PoC esegue la seguente sequenza da un container non privilegiato:

1. Entra in nuovi user e network namespace con unshare(CLONE_NEWUSER | CLONE_NEWNET).
2. Registra molte Security Association xfrm i cui campi di sequenza elevati codificano chunk di payload da 4 byte.
3. Apre un binario target dal livello di immagine condiviso in sola lettura.
4. Usa splice() e input ESP appositamente costruiti per attivare il percorso vulnerabile del kernel.
5. Ripete il primitivo finché i contenuti della page cache del binario target non contengono il payload incorporato.

Non è richiesto alcun permesso di scrittura sul file target. Il file su disco rimane invariato — solo la page cache in memoria viene corrotta.

2. Propagazione tra Container tramite Livelli Condivisi

I runtime container servono le letture dai livelli inferiori overlay tramite la page cache del kernel. Se il container PoC e kube-proxy condividono lo stesso file di livello inferiore, entrambi osservano le stesse pagine in cache.

L'immagine EKS in questo repository è costruita da:

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

Quella base è scelta per corrispondere al livello della toolchain userspace kube-proxy EKS usato nell'ambiente validato.

3. Esecuzione Privilegiata da kube-proxy

Quando kube-proxy esegue successivamente un binario della famiglia iptables patchato, il kernel carica le pagine in cache corrotte. Il payload PoC monta il dispositivo root dell'host e scrive un file marcatore in /root/res.

Il contenuto atteso del marcatore è:

[*] success

Diagramma del Flusso di Attacco

┌──────────────────────────────┐     ┌────────────────────────┐     ┌──────────────────────────┐
│  Pod PoC                     │     │  Page Cache del Kernel │     │  DaemonSet kube-proxy    │
│  container non privilegiato  │     │                        │     │  container privilegiato  │
│                              │     │                        │     │                          │
│  1. unshare user+net ns      │     │                        │     │                          │
│  2. installa SA xfrm         │     │                        │     │                          │
│  3. splice binario target    │────▶│  binario livello       │────▶│  esegue binario patchato │
│     tramite percorso ESP     │     │  condiviso page cache  │     │  payload gira con        │
│                              │     │  patchato              │     │  privilegi di nodo       │
└──────────────────────────────┘     └────────────────────────┘     └──────────────────────────┘

Ambiente Validato

Amazon EKS

GKE e ACK — Testati, Non Sfruttabili con Configurazione Predefinita

Ho testato su cluster GKE e ACK. Tutti falliti.

Il primitivo Dirty Frag richiede la creazione di user namespace (CLONE_NEWUSER) per ottenere CAP_NET_ADMIN all'interno di un nuovo network namespace. Sia ACK che GKE bloccano questo a livello di nodo tramite meccanismi diversi:

• ACK: La restrizione a livello di kernel (user.max_user_namespaces=0) impedisce completamente la creazione di user namespace non privilegiati.
• GKE: Il profilo seccomp predefinito (abilitato dal flag --seccomp-default di kubelet) blocca la syscall unshare indipendentemente dal limite dei namespace.

Questa è una differenza chiave rispetto a Copy Fail (CVE-2026-31431), che non richiede user namespace e sfrutta con successo tutte e tre le piattaforme.

kube-proxy come Esempio Concreto

La variante EKS fornita patch i seguenti binari quando presenti:

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

Questi binari vengono invocati dalla toolchain iptables usata da kube-proxy. La tempistica esatta del trigger dipende dall'attività di riconciliazione di nodi e servizi. Nell'ambiente validato, il payload è stato attivato dalla normale riconciliazione di kube-proxy.

Avvertenze importanti:

• kube-proxy invoca ipset solo quando configurato in modalità ipvs. La modalità predefinita (iptables) non usa ipset.
• Alcune distribuzioni Kubernetes gestite eseguono kube-proxy come container non privilegiato, il che limita l'impatto dell'escape.
• Il PoC targetizza più binari (xtables-legacy-multi, xtables-nft-multi) per coprire diverse modalità proxy, ma se vengono invocati dipende dalla configurazione del cluster.

Se kube-proxy non è privilegiato nel tuo cluster, il principio di attacco rimane valido — devi solo identificare un diverso DaemonSet privilegiato che condivida livelli di immagine con un'immagine base da cui puoi costruire.

Struttura del Repository

.
├── exploit/
│   └── dirtyfrag.c              # Scrittore page cache xfrm/ESP
├── payload/
│   ├── payload-eks.c            # Payload nolibc che scrive /root/res sull'host
│   └── nolibc/                  # Header Linux nolibc
├── deploy/
│   └── poc-eks.yaml             # Manifest Deployment EKS non privilegiato
├── scripts/
│   ├── setup-eks.sh             # Copia, compila e importa l'immagine su un nodo EKS
│   ├── run-poc.sh               # Distribuisce e verifica il marcatore
│   └── cleanup.sh              # Rimuove pod, marcatore, pagine in cache e immagine locale
├── Dockerfile.eks               # Immagine EKS basata su eks-distro-minimal-base-iptables
├── Makefile                     # Target di build per payload, exploit, Docker e nerdctl
└── .github/workflows/
    └── docker-publish.yml       # Workflow di pubblicazione GHCR

Build e Utilizzo

# Compila payload + binario exploit
make build-eks CC=x86_64-linux-gnu-gcc

# Compila immagine Docker
make docker-build-eks

# Distribuisci (pod non privilegiato)
kubectl apply -f deploy/poc-eks.yaml

# Controlla i log
kubectl logs deployment/dirtyfrag-poc-eks

# Verifica l'escape sul nodo
ssh ec2-user@<node-ip> "sudo cat /root/res"
# Atteso: [*] success

Il workflow GitHub Actions (.github/workflows/docker-publish.yml) pubblica l'immagine su GHCR al push su main o alla creazione di un tag. Sostituisci <owner> in deploy/poc-eks.yaml con l'utente o l'organizzazione GitHub che possiede il fork.

Pulizia

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

Versioni Interessate

• Kernel Linux: Tutte le versioni precedenti alla patch di CVE-2026-43284 (commit f4c50a4034e6).
• Kubernetes: Qualsiasi versione che usi un kernel nodo non patchato con user namespace abilitati. La vulnerabilità è nel kernel, non in Kubernetes stesso. Kubernetes fornisce semplicemente il contesto di esecuzione (livelli di immagine condivisi + DaemonSet privilegiati) che eleva l'impatto da corruzione locale della page cache a container escape completo.

Mitigazione

• Patcha il kernel. Aggiorna a un kernel contenente il fix di Dirty Frag, incluso il commit f4c50a4034e6 o il backport del vendor.
• Disabilita i moduli ESP non usati. Blocca esp4 e esp6 se IPsec ESP non è richiesto sui nodi worker.
• Limita gli user namespace. Impostare user.max_user_namespaces=0 impedisce a questo PoC di ottenere CAP_NET_ADMIN in un nuovo network namespace (questo è già il predefinito su ACK).
• Usa profili seccomp restrittivi. RuntimeDefault o profili personalizzati possono bloccare syscall chiave di namespace e networking (questo è già il predefinito su GKE).
• Minimizza i DaemonSet privilegiati. Evita privileged: true e ampio accesso host se non strettamente necessario.
• Riduci la condivisione di livelli con workload privilegiati. Usa immagini base distinte per agenti privilegiati e controlla dove possono essere eseguiti workload non fidati.

Esempio di blocco modulo:

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

Crediti

• Ricerca Dirty Frag ed exploit originale: V4bel/dirtyfrag

Riferimenti

• Dirty Frag - V4bel/dirtyfrag
• Copertura LWN
• Discussione CVE-2026-43284 xfrm/ESP
• Copy Fail Kubernetes PoC

Licenza

Il codice dell'exploit è adattato da V4bel/dirtyfrag sotto licenza MIT.

Il codice del payload deriva da tgies/copy-fail-c ed è concesso in doppia licenza LGPL-2.1-or-later OPPURE MIT.

Gli header nolibc provengono dall'infrastruttura di self-test del kernel Linux.