percivalll/dirty-frag-kubernetes-pocProof-of-Concept, das einen Container-Ausbruch auf Amazon EKS demonstriert, indem es Dirty Frag (CVE-2026-43284) Kernel-Page-Cache-Korruption über gemeinsame Image-Layer und privilegierte DaemonSets ausnutzt.
Ein Proof-of-Concept, der demonstriert, wie ein standardmäßiger, unprivilegierter Kubernetes-Pod auf Amazon EKS Codeausführung auf Knotenebene erreichen kann, indem die Dirty-Frag-Linux-Kernel-Page-Cache-Korruptions-Schwachstelle über gemeinsame Container-Image-Layer ausgenutzt wird.
Die zentrale Angriffsprimitive lautet: Jedes privilegierte DaemonSet, das Image-Layer mit einem angreiferkontrollierten Container teilt, kann für einen Container-Escape bewaffnet werden. Dieses PoC verwendet kube-proxy als ein konkretes Beispiel, aber die Technik lässt sich auf jede privilegierte Workload im Cluster verallgemeinern.
Validierung auf Amazon EKS (Kernel 6.12.80) — ein unprivilegierter Pod schreibt [*] success über das privilegierte kube-proxy-DaemonSet in das Host-Dateisystem:
Haftungsausschluss: Dieses Repository wird ausschließlich zu Bildungs- und Verteidigungszwecken veröffentlicht. Verwenden Sie es ausschließlich auf Systemen, die Sie besitzen oder für deren Test Sie ausdrücklich autorisiert sind.
Dirty Frag (CVE-2026-43284) ist eine Linux-Kernel-Page-Cache-Korruptions-Schwachstelle im xfrm/ESP-Empfangspfad. Im betroffenen Pfad kann esp_input() skb_cow_data() für ein nicht-lineares skb ohne frag_list überspringen, wodurch crypto_authenc_esn_decrypt() 4 Bytes angreiferkontrollierter Daten in eine Page-Cache-Seite speichern kann, die über splice() erreicht wird.
Die Datei auf der Festplatte wird nicht verändert. Die korrupten Bytes befinden sich im Kernel-Page-Cache und werden von späteren Lesern derselben gecachten Dateiseite beobachtet.
Vollständige Details zur ursprünglichen Schwachstelle finden Sie unter V4bel/dirtyfrag.
Der Angriff nutzt drei Eigenschaften aus, die in Kubernetes-Clustern häufig gemeinsam auftreten:
privileged: true, hostNetwork: true, umfangreiche Capabilities usw.), die regelmäßig Binärdateien aus ihrem Image ausführen.Wenn diese Bedingungen zusammentreffen, kann ein unprivilegierter Pod eine Binärdatei in einem gemeinsamen Image-Layer korrumpieren, und ein privilegiertes DaemonSet auf demselben Knoten führt die korrumpierte Binärdatei unwissentlich mit seinen erhöhten Privilegien aus — was eine vollständige Codeausführung auf Knotenebene erreicht.
Das Angriffsziel ist NICHT auf kube-proxy beschränkt. Jedes privilegierte DaemonSet (Monitoring-Agenten, CNI-Plugins, Log-Collector, Sicherheitsagenten usw.), dessen Container-Image Layer mit einem angreiferkontrollierten Image teilt, ist ein geeignetes Ziel.
Dieses Projekt ist vom Kubernetes-Ausbeutungsmodell inspiriert, das im Copy Fail Kubernetes PoC dokumentiert ist, verwendet jedoch eine andere Kernel-Primitive.
| Eigenschaft | Copy Fail | Dirty Frag |
|---|---|---|
| CVE | CVE-2026-31431 | CVE-2026-43284 |
| Kernel-Pfad | AF_ALG + splice() | xfrm/ESP + splice() |
| Namespace-Anforderung | Nicht erforderlich | Erfordert User-Namespaces |
| Haupt-Capability | Keine im anfänglichen Container | CAP_NET_ADMIN innerhalb des neuen Netzwerk-Namespace |
| Relevantes Modul | algif_aead | esp4 |
| Praktischer Unterschied | Bricht, wenn AF_ALG-Vektor blockiert ist | Weiterhin relevant, wenn AF_ALG nicht verfügbar ist, aber ESP/User-Namespaces aktiviert sind |
Die Angriffskette hat drei Phasen: Page-Cache-Korruption, containerübergreifende Ausbreitung und privilegierte Ausführung.
Die PoC-Binärdatei führt die folgende Sequenz aus einem unprivilegierten Container aus:
unshare(CLONE_NEWUSER | CLONE_NEWNET) in neue User- und Netzwerk-Namespaces.splice() und konstruierte ESP-Eingaben, um den verwundbaren Kernel-Pfad auszulösen.Für die Zieldatei ist keine Schreibberechtigung erforderlich. Die Datei auf der Festplatte bleibt unverändert — nur der In-Memory-Page-Cache wird korrumpiert.
Container-Runtimes bedienen Lesevorgänge aus Overlay-Lower-Layern über den Kernel-Page-Cache. Wenn der PoC-Container und kube-proxy dieselbe Lower-Layer-Datei teilen, beobachten beide dieselben gecachten Seiten.
Das EKS-Image in diesem Repository basiert auf:
public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables:2026-03-11-1773190710.2023
Diese Basis wurde gewählt, um mit der EKS-kube-proxy-Userspace-Toolchain-Schicht übereinzustimmen, die in der validierten Umgebung verwendet wird.
Wenn kube-proxy als Nächstes eine gepatchte iptables-Familien-Binärdatei ausführt, lädt der Kernel die korrumpierten gecachten Seiten. Die PoC-Payload mountet das Host-Root-Gerät und schreibt eine Markierungsdatei nach /root/res.
Der erwartete Markierungsinhalt ist:
[*] success
┌──────────────────────────────┐ ┌────────────────────────┐ ┌──────────────────────────┐
│ PoC-Pod │ │ Kernel-Page-Cache │ │ kube-proxy-DaemonSet │
│ unprivilegierter Container │ │ │ │ privilegierter Container│
│ │ │ │ │ │
│ 1. unshare user+net ns │ │ │ │ │
│ 2. xfrm-SAs installieren │ │ │ │ │
│ 3. Ziel-Binärdatei splices │────▶│ Shared-Layer-Binärdatei│────▶│ führt gepatchte Binär- │
│ über ESP-Pfad │ │ Page-Cache gepatcht │ │ datei aus; Payload läuft│
│ │ │ │ │ mit Privilegien auf │
│ │ │ │ │ Knotenebene │
└──────────────────────────────┘ └────────────────────────┘ └──────────────────────────┘