Copy Fail (CVE-2026-31431) — Proof of Concept per l'Escape da Container Kubernetes

Un proof-of-concept che dimostra come un container completamente non privilegiato possa ottenere esecuzione di codice a livello di nodo su Kubernetes sfruttando il bug di corruzione della page-cache del kernel Linux CVE-2026-31431 tramite layer di immagini condivise.

La primitiva di attacco principale è: qualsiasi DaemonSet privilegiato che condivide layer di immagini con un container controllato dall'attaccante può essere armato per l'escape dal container. Questo PoC utilizza kube-proxy come esempio concreto, ma la tecnica si generalizza a qualsiasi carico di lavoro privilegiato nel cluster.

Validato su Alibaba Cloud ACK, Amazon EKS e Google GKE — un pod non privilegiato scrive [*] success nel filesystem dell'host tramite il DaemonSet privilegiato kube-proxy:

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

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

Contesto

CVE-2026-31431 ("Copy Fail") è una vulnerabilità del kernel Linux nel percorso Copy-on-Write (CoW) della page-cache. Una race condition AF_ALG splice permette a un processo non privilegiato di corrompere le pagine della page-cache di un file sola lettura. La corruzione persiste nella cache delle pagine del kernel ed è visibile a qualsiasi processo che successivamente legge o esegue il file — inclusi i processi in altri container o sull'host.

Per tutti i dettagli sulla vulnerabilità originale, consulta copy.fail.

Principio di Attacco

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

1. Corruzione della page-cache del kernel (CVE-2026-31431) — un processo non privilegiato può sovrascrivere le pagine cache in memoria di qualsiasi file che può aprire in sola lettura.
2. Condivisione dei layer di immagine — i runtime dei container (containerd, CRI-O) utilizzano filesystem overlay dove layer 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, capacità estese, ecc.) che eseguono periodicamente binari dalla loro immagine.

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

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

Come Funziona

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

1. Corruzione della Page-Cache tramite Race Condition AF_ALG Splice

Il sottosistema AF_ALG (crittografia) del kernel espone un'interfaccia basata su socket per operazioni crittografiche in spazio utente. L'exploit abusa di una race condition nel modo in cui il kernel gestisce splice() da un file in un socket AF_ALG:

1. Apri il binario target in sola lettura.
2. Crea un socket AF_ALG AEAD associato a authencesn(hmac(sha256),cbc(aes)).
3. Invia un piccolo chunk di payload attraverso il socket AF_ALG con MSG_MORE, dicendo al kernel di aspettarsi più dati.
4. splice() il contenuto del file target da un fd → pipe → socket AF_ALG.
5. A causa del bug CoW, il kernel scrive i byte del payload dell'attaccante nelle pagine della page-cache del file target invece di isolarli correttamente.

L'exploit ripete questa operazione per ogni finestra di 4 byte fino a quando tutte le pagine nella cache del binario target non vengono sovrascritte con un payload personalizzato.

Non è necessaria alcuna autorizzazione di scrittura sul file. Il file su disco rimane invariato — solo la cache delle pagine in memoria viene corrotta.

2. Propagazione Cross-Container tramite Condivisione dei Layer di Immagine

I runtime dei container utilizzano filesystem overlay. Quando due container condividono lo stesso layer di immagine, il kernel serve le letture dei loro file dalle stesse pagine della page-cache.

L'attaccante costruisce la propria immagine PoC FROM la stessa immagine base del DaemonSet privilegiato target. Poiché entrambi i container condividono lo stesso lower-dir overlay, i binari nel layer condiviso mappano a pagine della page-cache identiche.

Quando il container PoC non privilegiato corrompe la page-cache di un binario, la corruzione è immediatamente visibile al container privilegiato sullo stesso nodo — con zero comunicazione cross-container.

3. Esecuzione Privilegiata da Parte del DaemonSet Target

Quando il DaemonSet privilegiato esegue successivamente un binario corrotto (attraverso il suo normale ciclo operativo), il kernel carica le pagine corrotte della page-cache. Il payload dell'attaccante viene eseguito con tutti i privilegi del DaemonSet — includendo potenzialmente:

• Root completo sul nodo
• Tutte le capacità
• Accesso ai namespace dell'host (rete, PID, mount)

Il payload in questo PoC (payload/payload.c) monta semplicemente il filesystem root dell'host e scrive un file marker in /root/res come prova dell'esecuzione di codice a livello di nodo.

Diagramma del Flusso di Attacco

┌──────────────────────────┐     ┌──────────────────────────┐
│   Container PoC          │     │   DaemonSet Privilegiato │
│   (non privilegiato)     │     │   (es. kube-proxy,       │
│                          │     │    agente di monitoraggio)│
│  1. Apri binario target  │     │                          │
│     (sola lettura)       │     │                          │
│                          │     │                          │
│  2. Race condition       │     │                          │
│     AF_ALG splice        │     │                          │
│     corrompe page-cache  │     │                          │
│          │               │     │                          │
└──────────┼───────────────┘     └──────────────────────────┘
           │                                  │
           ▼                                  │
  ┌─────────────────────┐                     │
  │  Pagine del Kernel   │                     │
  │  (Page Cache)        │                     │
  │                      │◄────────────────────┘
  │  Binario del layer   │     3. Il DaemonSet esegue il
  │  condiviso           │        binario corrotto
  │  (CORROTTO)          │        → carica pagine corrotte
  │  contiene byte       │        → payload eseguito con
  │  del payload         │           privilegi del DaemonSet
  └─────────────────────┘

Ambienti Cloud Validati

Il PoC è stato validato con successo sulle seguenti piattaforme Kubernetes gestite:

Alibaba Cloud ACK

Amazon EKS

Google GKE

In tutti e tre i casi, un pod PoC non privilegiato ha scritto con successo il file marker [*] success nel filesystem dell'host — dimostrando l'esecuzione di codice a livello di nodo tramite il DaemonSet privilegiato kube-proxy.

Per le guide complete (analisi dei layer di immagine, passaggi di build, distribuzione):

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

kube-proxy come Esempio Concreto

Questo PoC utilizza kube-proxy come target perché è uno dei DaemonSet privilegiati più comuni nei cluster Kubernetes. Sono fornite tre varianti:

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

Tutte le varianti corrompono binari come /usr/sbin/ipset, /usr/sbin/nft, /usr/sbin/xtables-legacy-multi e /usr/sbin/xtables-nft-multi.

Avvertenze importanti:

• kube-proxy invoca ipset solo quando configurato in modalità ipvs. La modalità predefinita (iptables) non utilizza ipset. Vedi kubernetes/enhancements#5495 per il piano di deprecazione di ipvs.
• Alcune distribuzioni Kubernetes gestite (es. alcuni provider cloud) eseguono kube-proxy come container non privilegiato, limitando l'impatto dell'escape.
• Il PoC ha come target più binari (ipset, nft, xtables-legacy-multi, xtables-nft-multi) per coprire diverse modalità proxy, ma se vengano invocati dipende dalla configurazione del cluster.

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

Generalizzazione ad Altri Target

Per adattare questo PoC a un diverso DaemonSet privilegiato:

1. Identifica un DaemonSet privilegiato in esecuzione nel cluster (agenti di monitoraggio, plugin CNI, collettori di log, ecc.).
2. Costruisci la tua immagine PoC FROM la stessa immagine base utilizzata da quel DaemonSet.
3. Identifica i binari nel layer condiviso che il DaemonSet eseguirà durante il suo normale funzionamento.
4. Corrompi la loro page-cache usando l'exploit.

Struttura del Repository

.
├── cmd/copyfail/main.go          # Entry point; incorpora il payload compilato
├── internal/
│   ├── exploit/
│   │   ├── exploit.go            # Exploit principale: ciclo di race condition AF_ALG splice
│   │   └── patch.go              # Divide il payload in finestre di patch da 4 byte
│   └── alg/
│       └── alg.go                # Astrazione del socket AF_ALG AEAD
├── payload/
│   ├── payload.c                 # Payload ACK/upstream (monta /dev/vda3 ext4)
│   ├── payload-eks.c             # Payload EKS (rilevamento automatico NVMe/Xen)
│   ├── payload-gke.c             # Payload GKE (rilevamento automatico COS/Ubuntu)
│   └── nolibc/                   # Libc minimale del kernel per payload statici senza dipendenze
├── deploy/
│   ├── poc.yaml                  # Manifesto Deployment Kubernetes (ACK/upstream)
│   ├── poc-eks.yaml              # Manifesto Deployment EKS
│   └── poc-gke.yaml              # Manifesto 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                      # Orchestrazione build (include target *-eks e *-gke)
└── docs/
    ├── eks-poc.md                # Guida completa PoC EKS
    ├── gke-poc.md                # Guida completa PoC GKE
    ├── ack-poc-res.png           # Screenshot validazione ACK
    ├── eks-poc-res.png           # Screenshot validazione EKS
    └── gke-poc-res.png           # Screenshot validazione GKE

Prerequisiti

• Go 1.25+
• Un cross-compilatore per il payload nolibc (predefinito: x86_64-linux-gnu-gcc)
• Docker / Buildx
• Un cluster Kubernetes con un DaemonSet privilegiato che condivide layer di immagini con l'immagine PoC (l'esempio predefinito ha come target kube-proxy)
• imagePullPolicy: IfNotPresent sul DaemonSet target (impostazione predefinita di Kubernetes)
• Kernel Linux prima della correzione di CVE-2026-31431

Build

ACK / Upstream Kubernetes

# Build payload + binario Go
make build

# Build immagine Docker
make docker-build

# Build e push su GHCR
make docker-push IMAGE=ghcr.io/<tuo>/copy-fail-poc TAG=latest

Amazon EKS

# Build payload EKS + binario Go + immagine Docker
make docker-build-eks

# Build e push su GHCR
make docker-push-eks IMAGE=ghcr.io/<tuo>/copy-fail-poc

Per target arm64 (Graviton):

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

Google GKE

# Build payload GKE + binario Go + immagine Docker
make docker-build-gke

# Build e push su GHCR
make docker-push-gke IMAGE=ghcr.io/<tuo>/copy-fail-poc

Per nodi arm64:

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

Utilizzo

Distribuisci il 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

Il Deployment crea un singolo pod non privilegiato. Questo:

1. Esegue /bin/copyfail per corrompere la page-cache dei binari target nel layer di immagine condiviso.
2. Resta in sleep indefinitamente in modo che il pod rimanga in esecuzione per l'osservazione.

Verifica l'Escape

Dopo che il DaemonSet privilegiato target esegue un binario corrotto (per kube-proxy, questo avviene in genere entro secondi grazie al suo ciclo di riconciliazione), controlla il nodo:

# SSH nel nodo, oppure usa un pod debug privilegiato

# ACK / EKS (filesystem root scrivibile)
cat /root/res
# Output atteso: [*] success

# Nodi COS GKE (root sola lettura, partizione statale scrivibile)
cat /mnt/stateful_partition/copyfail-res
# Output atteso: [*] success

La presenza del file marker sul filesystem dell'host prova che il codice fornito dall'attaccante è stato eseguito con privilegi a livello di nodo — dal contesto del container del DaemonSet privilegiato.

Pulizia

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

# Sul(i) nodo(i) interessato(i), rimuovi il marker e riavvia il DaemonSet target:
rm -f /root/res                                     # ACK / EKS
rm -f /copyfail-res /mnt/stateful_partition/copyfail-res  # Nodi COS GKE
# Per kube-proxy: elimina il pod per forzare la rilettura del layer di immagine
kubectl delete pod -n kube-system -l k8s-app=kube-proxy --field-selector spec.nodeName=<nodo>

Personalizzare il Payload

Il payload predefinito (payload/payload.c) è un programma solo di validazione che scrive un file marker. Per costruire un payload personalizzato:

1. Modifica payload/payload.c. Il programma è compilato con nolibc (la libreria C minima del kernel) per un binario statico, senza dipendenze.
2. Esegui make payload per cross-compilare.
3. Il payload compilato viene incorporato nel binario Go tramite //go:embed.

Versioni Affette

• Kernel Linux: Tutte le versioni precedenti alla patch di CVE-2026-31431.
• Kubernetes: Qualsiasi versione che utilizzi un kernel del nodo non patchato. La vulnerabilità è nel kernel, non in Kubernetes stesso. Kubernetes fornisce solo il contesto di esecuzione (layer di immagine condivisi + DaemonSet privilegiati) che eleva l'impatto da corruzione locale della page-cache a fuga completa dal container.

Mitigazione

• Applica la patch al kernel. È la soluzione definitiva.
• Abilita l'isolamento dei layer di immagine. Alcuni runtime supportano snapshot per-container del filesystem che impediscono la condivisione della page-cache.
• Minimizza i DaemonSet privilegiati. Riduci il numero di carichi di lavoro con privilegi elevati; utilizza il principio del minimo privilegio.
• Rimuovi capacità non necessarie dai DaemonSet che non richiedono strettamente privileged: true.
• Limita lo scheduling dei pod per impedire che carichi di lavoro non fidati vengano posizionati su nodi che eseguono DaemonSet privilegiati con immagini base condivise.
• Utilizza immagini base distinte per i carichi di lavoro privilegiati per ridurre la probabilità di condivisione di layer con container non fidati.

Esempi di Mitigazione

• Regola di mitigazione integrata in vArmor: copy-fail-mitigation blocca il vettore d'attacco impedendo ai container di creare socket AF_ALG. La regola è disponibile tramite gli enforcer AppArmor e BPF.
• Mitigazione eBPF per Kubernetes: iwanhae/copyfail-ebpf-k8s fornisce un esempio di mitigazione eBPF per Kubernetes per CVE-2026-31431.

Crediti

• Scoperta e divulgazione di CVE-2026-31431: Theori / Xint
• Payload C multipiattaforma: Tony Gies (LGPL-2.1-or-later OR MIT)
• nolibc: Test automatici del kernel Linux (tools/include/nolibc/)

Licenza

Il codice Go dell'exploit in questo repository è fornito così com'è a scopo di ricerca.

Il payload (payload/payload.c) è derivato da copy-fail-c ed è concesso in doppia licenza LGPL-2.1-or-later OR MIT. Vedi LICENSE-LGPL e LICENSE-MIT.