DirtyFrag CVE-2026-43284 PoC-Validierung und auditd-Erkennung

Umfang: Validierung der Linux Local Privilege Escalation (LPE) mit Fokus auf den XFRM/ESP-Pfad im Zusammenhang mit CVE-2026-43284.

Dieses Repository enthält einen englischen Bericht und Beweisartefakte aus einer kontrollierten Laborvalidierung des öffentlichen DirtyFrag-PoCs. Der Schwerpunkt liegt nicht auf einer Exploit-Anleitung, sondern darauf, zu dokumentieren, was in den Linux-Audit-Logs sichtbar war und wie diese Ereignisse in praktische SOC-Erkennungslogik umgewandelt werden können.

Vollständiger PDF-Bericht:

EN: reports/DirtyFrag_CVE-2026-43284_EN.pdf

PL: reports/DirtyFrag_CVE-2026-43284_PL.pdf

Zweck und Umfang

Der Test wurde durchgeführt, um zu überprüfen, ob ein normaler lokaler Benutzer in einer verwundbaren Labor-VM eine Root-Shell erhalten kann, und um festzustellen, welche Ereignisse mit auditd erfasst werden können.

CVE-2026-43284 betrifft die unsachgemäße Behandlung gemeinsamer Seitenfragmente während ESP/IPsec-Operationen. Unter bestimmten Bedingungen kann ein lokaler Angreifer Daten im Page-Cache beeinflussen und Privilegien erweitern. Ubuntu Security stuft diese Schwachstelle als CVSS 3.1: 7.8 High ein.

Technische Referenzen:

• Öffentliches DirtyFrag-PoC-Repository: https://github.com/V4bel/dirtyfrag
• Ubuntu Security – CVE-2026-43284: https://ubuntu.com/security/CVE-2026-43284
• Ubuntu-Blog – Dirty Frag Linux-Sicherheitsupdates verfügbar: https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available

Testumgebung

Vollständige Systembasislinie: evidence/logs/system-info-table.md

Ergebnis

Vor der PoC-Ausführung war der Testkontext ein normales Benutzerkonto. Nach Ausführung von ./exp wurde eine Root-Shell erhalten und mit whoami und id bestätigt.

Beweissammlung

Nach dem Test wurden auditd-Logs und Zusammenfassungsausgaben in ein lokales Beweisverzeichnis exportiert und in dieses Repository kopiert.

Repository-Struktur

auditd-Erkennungslogik

Die nützlichste Erkennung ist kein einzelnes Ereignis. Das stärkste Signal ist die gesamte Kette, die in einem kurzen Zeitfenster beobachtet wird:

user namespace -> vmsplice/splice -> ESP/XFRM -> su -> root shell with AUID of a normal user

Relevante auditd-Keys

Rekonstruierte Ereigniskette

Beispiel-SIEM-Korrelation

IF
  dirty_frag_unshare by auid>=1000
  AND count(dirty_frag_vmsplice + dirty_frag_splice by same exe or pid) >= 3 within 600s
  AND MAC_IPSEC_EVENT / XFRM activity within 1200s
  AND (dirty_frag_su_exec OR execve with euid=0 and auid>=1000) within 1200s
THEN
  alert = "Possible DirtyFrag CVE-2026-43284 Linux LPE"
  severity = high/critical

SOC-Empfehlungen

• Kernel patchen und nach Updates einen Neustart in den gepatchten Kernel erzwingen.
• Syscall-Telemetrie mit auditd, Falco, eBPF-basierten Tools oder EDR sammeln.
• Nicht allein auf ein einzelnes euid=0-Ereignis alarmieren; dies erfasst auch legitime sudo-Nutzung.
• unshare, vmsplice, splice, XFRM/ESP-Aktivität, su und die Erstellung von Root-Prozessen aus einer normalen Benutzersitzung korrelieren.
• Erwägen, kernel.unprivileged_userns_clone einzuschränken, wo die Anwendungskompatibilität dies erlaubt.
• Prüfen, ob ESP/IPsec-Module auf einer bestimmten Hostklasse erforderlich sind, und unnötiges Laden von Modulen gegebenenfalls einschränken.
• Logs an einen entfernten Collector oder SIEM weiterleiten; nach einer LPE können lokale Logs vom Angreifer verändert werden.
• auditd-Qualität überwachen: lost sollte während Tests und Produktionsüberwachung 0 bleiben.
• Ein Linux-LPE-Triage-Playbook pflegen, das Host-Isolation, Audit-Log-Sammlung, Kernel-Verifizierung des laufenden Systems und Erfassung geladener Module abdeckt.

Hinweise

Der gesammelte auditd-Status zeigte lost=2555, was bedeutet, dass einige Audit-Ereignisse verworfen worden sein könnten. Die Schlüsselkette ist weiterhin sichtbar, aber zukünftige Tests sollten den Audit-Backlog erhöhen und vor der Ausführung des PoCs lost=0 bestätigen.

Der Bericht konzentriert sich bewusst auf CVE-2026-43284 / XFRM/ESP, um den SOC-Erkennungsumfang nicht mit anderen DirtyFrag-bezogenen Pfaden zu vermischen.