tetragon-dirtyfrag

Blockieren der DirtyFrag Linux-Privilegieneskalationskette (CVE-2026-43284 / CVE-2026-43500) zur Laufzeit mit einer Cilium Tetragon TracingPolicy. Die Policy sendet SIGKILL an den öffentlichen Proof-of-Concept bei seinem Socket-Setup-Schritt, bevor er den Page-Cache-Schreibvorgang erreicht, der ihm Root-Rechte geben würde.

Was das hier ist. Eine Labor-Dokumentation. Ich habe Tetragon zum ersten Mal eingerichtet und wollte sehen, ob es tatsächlich eine echte, aktuelle Kernel-LPE stoppen kann. Konnte es. Dies dokumentiert genau, was ich ausgeführt habe, was ausgelöst wurde und, genauso wichtig, die Grenzen dessen, was es beweist. Es ist kein Ersatz für Patching.

Dateien: Diese README (in sich geschlossen, Beweise inline) · block-dirtyfrag.yaml (die Policy)

---

Ergebnisse

Exploit	DirtyFrag - öffentlicher PoC: V4bel/dirtyfrag
CVEs	CVE-2026-43284 (xfrm-ESP-Page-Cache-Schreibzugriff), CVE-2026-43500 (RxRPC-Page-Cache-Schreibzugriff)
Host	Ubuntu 24.04.4 LTS, Tetragon v1.7.0 (Standalone, systemd)
Baseline - keine Policy, Kernel 6.8.0-88 (anfällig)	PoC → uid=0(root)
Mit Policy - Kernel 6.8.0-88	PoC SIGKILLed bei socket(AF_RXRPC); Benutzer bleibt uid=1000
Gepatcher Kernel 6.8.0-134	PoC schlägt von selbst fehl (rc=4); Socket-Hook feuert trotzdem, Erkennung, nicht Entschärfung (Anmerkung)
Art der Kontrolle	Kompensierende Kontrolle / virtueller Patch, keine Kernel-Fix

---

Was DirtyFrag ist (Kurzfassung)

DirtyFrag ist eine lokale Privilegieneskalationskette, die aus zwei unabhängigen Page-Cache-Schreibprimitive im Linux-Kernel besteht: eine im xfrm/ESP (IPsec) In-Place-Entschlüsselungspfad (CVE-2026-43284) und eine im RxRPC-Pfad (CVE-2026-43500). Jede erlaubt es einem unprivilegierten lokalen Benutzer, vom Angreifer kontrollierte Bytes in schreibgeschützte Page-Cache-Seiten zu schreiben, z. B. in das gecachte Image einer setuid-root-Binärdatei wie /bin/su – und von dort Root zu erlangen. Der Schreibvorgang landet nur im Arbeitsspeicher; die Datei auf der Festplatte wird nie verändert, daher sieht die Dateiintegritätsüberwachung nichts. Es handelt sich um dieselbe Fehlerklasse wie Dirty Pipe und Copy Fail. Die beiden CVEs werden bewusst verkettet: Wenn ein Pfad in einer bestimmten Umgebung nicht verfügbar ist, funktioniert der andere trotzdem.

Auf diesem Host sind unprivilegierte Benutzernamensräume durch AppArmor eingeschränkt (kernel.apparmor_restrict_unprivileged_userns = 1), was die ESP-Hälfte der Kette blockiert. Das hinterlässt den RxRPC-Pfad, der einen AF_RXRPC-Socket (Adressfamilie 33) öffnet – und genau diesen Schritt tötet diese Policy.

Die eigentliche Lösung ist ein gepatchter Kernel. Alles hier ist ein Provisorium für einen Host, den Sie noch nicht patchen können. Ubuntu hat DirtyFrag-Fixes einige Zeit vor diesem Test ausgeliefert, daher handelt es sich um ein bekanntes N-Day, nicht um einen aktuellen 0-Day – der Punkt ist zu zeigen, was eine Laufzeitkontrolle auf einem Host tun kann, der aus irgendeinem Grund immer noch einen anfälligen Kernel ausführt.

---

Die Policy: zwei Engpässe

Vollständige Policy: block-dirtyfrag.yaml. Sie installiert zwei Kproben.

Hook 1 - Grooming-Sockets (sys_socket). Die tragende Kontrolle. Der RxRPC-Pfad des Exploits muss bei jedem Lauf socket(AF_RXRPC, …) aufrufen, unabhängig davon, ob ein Kernelmodul bereits geladen ist. Die Policy prüft auf die Adressfamilie:

• Familie 33 (AF_RXRPC) → Sigkill. Auf jedem Host, der kein AFS-Client ist, öffnet praktisch nichts Legitimes einen AF_RXRPC-Socket, daher ist ein pauschaler Kill hier sicher und mit hoher Sicherheit.
• Familie 38 (AF_ALG) → Post (nur Audit, kein Kill). AF_ALG ist die Userspace-Kernel-Krypto-API und hat legitime Benutzer (cryptsetup, libkcapi-Tooling, einige FIPS-Workflows). Ein Kill allein aufgrund der Familie würde Fehlalarme verursachen, daher protokolliert dieser Abschnitt nur. Der Weg zur Durchsetzung: Eine Weile auditen, eine NotIn-Allowlist aus den tatsächlich beobachteten Binärdateien erstellen, dann erwägen, auf Sigkill hochzustufen.

Hook 2 - Anfälliges Modul-Autoload (security_kernel_module_request). Verteidigung in der Tiefe. Wird ausgelöst, wenn der Kernel aufgefordert wird, eine anfällige Modulfamilie automatisch zu laden (esp4, esp6, rxrpc, die Socket-Aliase net-pf-33/net-pf-38, die Crypto-Templates pcbc/fcrypt). Einschränkung: Es wird nur ausgelöst, wenn das Modul noch nicht residiert – nach dem ersten Exploit-Lauf in einer Boot-Sitzung sind diese Module geladen und dieser Hook wird stumm. Es ist eine Kaltstart-Schicht, nicht die primäre Kontrolle.

Zusammen: Hook 1 erwischt den Exploit, egal ob Module warm oder kalt sind; Hook 2 fügt auf einem kalten Host eine frühere, spezifischere Auslösung hinzu.

---

Testumgebung & Reproduzierbarkeit (bitte lesen, bevor Sie dem Ergebnis vertrauen)

• Das Entschärfungsergebnis bezieht sich auf Kernel 6.8.0-88-generic, der anfällig ist (die Baseline erreicht Root). Die Box hat auch 6.8.0-134-generic installiert – den gepatchten Kernel – und dies wurde direkt bestätigt: Ein Neustart in -134 führt dazu, dass der PoC von selbst fehlschlägt (rc=4, kein Root), mit oder ohne Policy (siehe Anmerkung unten). Um die Entschärfungsdemo zu reproduzieren, booten Sie 6.8.0-88 über GRUB (es ist noch installiert) – auf einem gepatchten Kernel gibt es nichts zu entschärfen.
• Dies ist ein Host, ein Boot. Es demonstriert den Mechanismus; es ist keine Fehlalarmstudie. Bevor Sie so etwas in der Produktion durchsetzen, führen Sie es zunächst im Audit-Modus gegen repräsentative Workloads aus – insbesondere den AF_ALG-Abschnitt.
• BPF LSM ist hier nicht aktiviert (aktive LSMs: lockdown,capability,landlock,yama,apparmor – kein bpf). Daher erfolgt die Durchsetzung mittels Sigkill von der Kprobe, nicht durch ein In-Kernel-LSM-Verweigern. Der Kill erfolgt beim socket()-Syscall – vor der Schreibprimitive – und beendet den Prozess bei einem zwingend frühen Schritt, anstatt die "Schwachstelle selbst zu blockieren".

---

Schritt-für-Schritt-Durchlauf

Schritte 1–5 stammen alle aus derselben 6.8.0-88-Bootsitzung (der anfällige Kernel).

1. Umgebung - Ubuntu 24.04.4, Kernel 6.8.0-88-generic, Tetragon v1.7.0 aktiv unter systemd, unprivilegierte Userns eingeschränkt.

$ uname -r
6.8.0-88-generic
$ tetra version
CLI version: v1.7.0
$ systemctl is-active tetragon
active

2. Vorbedingungen (Policy AUS) - sauberer Ausgangspunkt: keine anfälligen Module geladen, kein xfrm-Status, keine Policy geladen.

$ lsmod | grep -E 'esp4|esp6|rxrpc' || echo "(keines geladen)"
(keines geladen)
$ sudo ip xfrm state          # (leer)
$ sudo tetra tp list
ID   NAME   STATE   FILTERID   NAMESPACE   SENSORS   KERNELMEMORY   MODE   NPOST   NENFORCE   NMONITOR

3. Baseline (Policy AUS) - der Exploit funktioniert. Das beweist, dass der Kernel tatsächlich anfällig ist; die gesamte Dokumentation beruht darauf.

$ ./exp ; id
uid=0(root) gid=0(root) groups=0(root)

4. Policy laden.

$ sudo tetra tp add /etc/tetragon/tetragon.tp.d/block-dirtyfrag.yaml
tracing policy "…/block-dirtyfrag.yaml" added