Root-Zugriff für lokale Benutzer
Was ist Dirty Frag?
Dirty Frag ist eine neue Linux-Zero-Day-Schwachstelle, die es lokalen Angreifern ermöglicht, mit einem einzigen Befehl Root-Rechte auf den meisten gängigen Linux-Distributionen zu erlangen. Sie besteht aus zwei miteinander verknüpften CVEs (CVE-2026-43284 und CVE-2026-43500), die zusammen eine schwerwiegende Schwachstelle zur lokalen Rechteausweitung (Local Privilege Escalation – LPE) im Linux-Kernel verursachen. Ein öffentlicher Exploit war bereits verfügbar, bevor Sicherheitsupdates bereitgestellt wurden.
Der Angriff missbraucht den sogenannten Zero-Copy-Send-Pfad, bei dem splice() eine Referenz auf eine schreibgeschützte Seite des Page Caches, beispielsweise /etc/passwd oder /usr/bin/su, in einen Netzwerkpuffer einfügt. Der Kernel führt anschließend kryptografische Operationen direkt auf dieser Seite aus und verändert sie dauerhaft im Arbeitsspeicher (RAM). Jeder nachfolgende Lesezugriff auf diese Datei liefert die manipulierte Version zurück, obwohl der Angreifer ursprünglich lediglich Leserechte besaß.
Da es sich um einen deterministischen Logikfehler ohne Race Condition handelt, ist kein Zeitfenster erforderlich. Der Kernel stürzt bei einem fehlgeschlagenen Versuch nicht ab, und die Erfolgsquote des Angriffs ist äußerst hoch.
Die Ziele des Dirty-Frag-Exploits
Das primäre Ziel ist die lokale Rechteausweitung (LPE): Ein Benutzer mit eingeschränkten Rechten auf einem Linux-System verschafft sich Root-Rechte. Dadurch können Angreifer, die bereits begrenzten Zugriff über gestohlene Zugangsdaten, Phishing oder eine andere Kompromittierung erlangt haben, die vollständige Kontrolle über ein System übernehmen.
Auf Hosts ohne Container-Workloads ermöglicht die Schwachstelle einem lokalen Benutzer die Erlangung von Root-Rechten. In Container-Umgebungen, in denen beliebige Workloads von Drittanbietern ausgeführt werden, kann die Schwachstelle zusätzlich einen Container Escape ermöglichen – neben der lokalen Rechteausweitung auf dem Host-System.
Der Exploit nutzt zwei Angriffswege, die jeweils die Schwächen des anderen ausgleichen: Zunächst wird der ESP-Pfad verwendet. Falls unshare(CLONE_NEWUSER) fehlschlägt, erfolgt automatisch ein Wechsel auf den RxRPC-Pfad, der /etc/passwd als Ziel verwendet.
Wer ist betroffen?
Zu den betroffenen Distributionen gehören unter anderem Red Hat Enterprise Linux, AlmaLinux, Debian, Ubuntu, Fedora, Arch Linux, CentOS, CloudLinux, Amazon Linux, sowie weitere Distributionen. In der Praxis bedeutet dies, dass nahezu jede Linux-Produktionsumgebung betroffen sein kann, die noch nicht gepatcht wurde.
Die ESP-Schwachstelle (CVE-2026-43284) wurde bereits im Januar 2017 eingeführt, wodurch die Schwachstellenkette fast neun Jahre lang bestanden hat.
Die Offenlegung wurde beschleunigt, nachdem eine dritte Partei das Embargo verletzt hatte. Der Sicherheitsforscher Hyunwoo Kim meldete beide Schwachstellen am 29. und 30. April 2026 vertraulich, sah sich jedoch gezwungen, die vollständige Dokumentation sowie den Proof of Concept (PoC) zu veröffentlichen, nachdem eine dritte Partei das Embargo am 7. Mai 2026 gebrochen hatte – noch bevor Sicherheitsupdates verfügbar waren.
Prävention: Patchen oder temporäre Gegenmaßnahmen
Schritt 1: So schnell wie möglich patchen
Für AlmaLinux sind gepatchte Kernel seit dem 8. Mai 2026 in den Produktions-Repositories verfügbar. Aktualisieren Sie das System und starten Sie es neu: sudo dnf clean metadata && sudo dnf upgrade kernel && sudo reboot. Überprüfen Sie nach dem Neustart, ob der gepatchte Kernel aktiv ist: uname -r. Konsultieren Sie die Sicherheitsmeldungen Ihrer Linux-Distribution für entsprechende Anweisungen.
Schritt 2: Temporäre Gegenmaßnahmen, falls ein sofortiges Patchen nicht möglich ist
Setzen Sie die betroffenen Kernel-Module auf die Blacklist:
- “echo "install esp4 /bin/false" >> /etc/modprobe.d/dirtyfrag.conf”
- “echo "install esp6 /bin/false" >> /etc/modprobe.d/dirtyfrag.conf”
- “echo "install rxrpc /bin/false" >> /etc/modprobe.d/dirtyfrag.conf”
- “modprobe -r esp4 esp6 rxrpc 2>/dev/null || true”
Beachten Sie, dass das Deaktivieren von esp4 und esp6 die Funktionalität von IPsec beeinträchtigt. Prüfen Sie daher vorab, ob Ihre Systeme aktiv IPsec oder AFS verwenden.
Schritt 3: Den Page Cache nach der Absicherung leeren
Der Exploit kann legitime Systemdateien im Page Cache verändern, um Root-Rechte zu erlangen. Die bloße Anwendung von Gegenmaßnahmen reicht daher auf Systemen nicht aus, die möglicherweise bereits vor deren Einführung angegriffen wurden. Leeren Sie nach der Absicherung den Page Cache:
- sync && echo 3 > /proc/sys/vm/drop_caches
Was nicht funktioniert
Die bestehende Copy-Fail-Mitigierung (Blacklisting von algif_aead) schützt nicht vor Dirty Frag. Systeme, die ausschließlich diese Maßnahme umgesetzt haben, bleiben vollständig verwundbar.
Fazit
Dirty Frag stellt eine ernsthafte Bedrohung für jede Linux-Umgebung dar. Der Exploit ist öffentlich verfügbar, deterministisch und funktioniert zuverlässig über zahlreiche Distributionen hinweg. Forscher warnen, dass Dirty Frag einen wachsenden Trend verdeutlicht: Linux-Schwachstellen werden immer schneller in praxistaugliche Angriffswerkzeuge umgewandelt.
Oberste Priorität hat die Installation der Kernel-Patches. Falls dies nicht sofort möglich ist, sollten die betroffenen Module deaktiviert und der Page Cache geleert werden. Prüfen Sie vor einer dauerhaften Deaktivierung der Module, ob IPsec oder AFS im Einsatz sind. Container-Umgebungen mit Mandanten- oder Mehrbenutzer-Workloads verdienen aufgrund des Risikos eines Container Escapes besondere Aufmerksamkeit.