MENU Schließen
Schließen

CVE-2026-43284 Dirty Frag – Universelle Linux-Rechteausweitung Teil 2

Sicherheitsforscher Hyunwoo Kim hat am 8. Mai 2026 eine Schwachstelle namens Dirty Frag veröffentlicht, die es ermöglicht, Root-Rechte auf allen gängigen Linux-Distributionen zu erlangen. Dieser ist ein Nachfolger von Copy Fail (CVE-2026-31431, CVSS 7.8), einer kürzlich bekannt gewordenen LPE-Schwachstelle im Linux-Kernel.

Es gibt mittlerweile einen Patch für Dirty Frag. Den aktuellen Status dazu findet man unter https://cve.enginsight.com/2026/43284/index.html oder bei den jeweiligen Distributionen (u.a. Debian: https://security-tracker.debian.org/tracker/CVE-2026-43284).

Es ist außerdem möglich die betroffenen Module, in denen die Sicherheitslücken aufreten, zu deaktivieren:

Code
sh c „printf ‚install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n‘ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true“

Nachteil:
IPsec und der kAFS-Treiber (Kernel-AFS-Dateisystem) funktionieren danach nicht mehr. Das beeinträchtigt IPsec basierte Tunnel sowie kAFS basierte Netzlaufwerke.

Quellen:

https://www.openwall.com/lists/oss-security/2026/05/07/8

https://moselwal.com/blog/linux-kernel-dirty-frag-lpe-mitigation

Wie funktioniert der Angriff

Dirty Frag nutzt einen Fehler in der Art, wie der Linux-Kernel verschlüsselte Netzwerkpakete verarbeitet. Normalerweise kopiert der Kernel empfangene Daten vor der Entschlüsselung in einen eigenen, privaten Speicherbereich. In einem Performance-Optimierungspfad der Subsysteme IPsec (esp4/esp6) und RxRPC prüft er jedoch nicht, ob die betreffende Speicherseite wirklich ihm allein gehört sondern entschlüsselt direkt in-place.

Ein Angreifer nutzt das aus, indem er über den Systemaufruf splice() eine Speicherseite, die er über eine Pipe kontrolliert, in den Netzwerkstack einschleust, so dass der Kernel sie als Empfangspuffer verwendet. Da der Angreifer das verschlüsselte Paket selbst konstruiert, bestimmt er auch, was der Kernel beim Entschlüsseln in diese Seite schreibt. Somit erhält er damit einen kontrollierten Schreibzugriff auf den Kernel-Speicher.

Dieser Schreibzugriff ist zunächst auf 4 Bytes begrenzt. Durch viele gezielte 4-Byte-Writes überschreibt der Angreifer schrittweise den Inhalt einer privilegierten Binärdatei wie sudo im Kernel-Speicher (Page Cache), ohne jemals Root-Rechte gehabt zu haben. Beim nächsten Aufruf dieser Datei führt das System den eingeschleusten Code mit Root-Rechten aus.

Vergleich Dirty Frag und CopyFail

Sowohl CopyFail als auch Dirty Frag gehören zur gleichen Fehlerkategorie und funktionieren nach demselben Grundprinzip. Dabei wird eine Speicherseite, die einem unprivilegierten Prozess gehört, durch einen Kernel-Subsystem-Fehler mit kontrollierten Daten überschrieben, wodurch sich Root Rechte erlangen lassen.

Der Unterschied liegt dabei im Eintrittspunkt. Copy Fail nutzt das Modul algif_aead (mehr Infos unter https://enginsight.com/de/blog/copyfail-cve-2026-31431-funktionsweise-erkennung-und-schutzmassnahmen-fuer-linux-systeme/), wohingegen Dirty Frag gleich zwei andere Eintrittspunkte nutzt. Die IPsec-Subsysteme esp4/esp6 sowie rxrpc aus dem RxRPC-Netzwerkstack. Das macht Dirty Frag breiter aufgestellt und erklärt, warum die Gegenmaßnahme gegen Copy Fail (Blacklisting von algif_aead) hier wirkungslos ist.

Erkennung über Enginsight

Die Sicherheitslücke kann über Enginsight zuverlässig erkannt werden:

  • Der Pulsar erkennt betroffene Systeme direkt über die ausgelesene Kernelversion.
  • Dabei wird die CVE solange als vorhanden erkannt, bis:
    1. der Sicherheits-Patch installiert wurde und
    2. das System vollständig neu gestartet wurde, sodass der aktualisierte Kernel aktiv läuft.
    Zusätzlich wird die Schwachstelle auch erkannt über:
  • den Observer bei öffentlich erreichbaren Websystemen,
  • sowie über den Hacktor im Rahmen von einem Pentest auf Systemen, auf die kein direkter Zugriff möglich ist.

Dadurch können auch externe oder eingeschränkt verwaltbare Systeme identifiziert werden.

Hinweis: Bitte beachten Sie, dass Sie bei einem Remote-Scan (wie Hacktor und Observer) ohne Authentifizierung meist nur eine Schätzung erhalten, da exakte Kernel-Versionen oft absichtlich verborgen werden. Bei kritischen Systemen empfehlen wir daher zusätzlich eine manuelle Kontrolle.

Inhalt

Mehr zum Thema:

Kommende Events & Webcasts:

Weitere Beiträge im Enginsight Blog

Axios NPM Supply Chain Kompromittierung

Am 30. März 2026 wurde das weit verbreitete NPM-Paket axios durch nordkoreanische Angreifer kompromittiert. Über einen übernommenen Maintainer-Account veröffentlichten sie zwei manipulierte Versionen, die den