„Dirty Frag“ (CVE-2026-43284): Der Fehler im Linux-Kernel, der Lesezugriff in Root-Rechte umwandelt

Eine schreibgeschützte Datei sollte schreibgeschützt bleiben. „Dirty Frag“ (CVE-2026-43284, CVE-2026-43500 und CVE-2026-46300) veranlasst den Linux-Kernel jedoch dazu, seine zwischengespeicherte Kopie trotzdem zu ändern.

Dieser Fehler ermöglicht es einem Programm, das mit nahezu keinen Berechtigungen läuft, in Dateien zu schreiben, die es eigentlich nur lesen dürfte, indem es die vom Kernel im Speicher gehaltene Kopie verändert. Von dort aus kann es Daten überschreiben, denen das System vertraut, und sich so Root-Zugriff verschaffen. In „container “-Umgebungen kann derselbe Trick, mit dem der Host-Kernel erreicht wird, auch den Knoten-Kernel erreichen, der von allen Workloads gemeinsam genutzt wird.

Die Sicherheitslücke ist seit Jahren im Netzwerkcode des Kernels vorhanden, weshalb sie sich über die meisten unterstützten Kernel-Versionen und nahezu alle großen Distributionen erstreckt. Linux hat die Schwachstelle behoben, und jede Distribution hat den Patch rückportiert, sodass die Korrektur in jeder Distribution unter einer anderen Versionsnummer zu finden ist.

„Dirty Frag“ im Überblick

Red Hat fasst drei CVEs unter dem Begriff „Dirty Frag“ zusammen. Sie befinden sich an verschiedenen Stellen im Netzwerkcode des Kernels, wobei es sich bei einer um eine spätere Variante handelt, die in der ersten Patch-Runde übersehen wurde. Hier ein Vergleich der drei Schwachstellen.

Das Subsystem gibt Ihnen Aufschluss darüber, ob dies für Sie relevant ist. Wenn Sie keine IPsec-VPNs oder AFS nutzen, ist dies ein schneller Anhaltspunkt dafür, inwieweit Sie sich darum kümmern sollten. Das Modul ist das, worauf Sie achten sollten (lsmod | grep -E 'esp4|esp6|rxrpc'), um zu sehen, was geladen ist.

Linux speichert die Daten der zuletzt aufgerufenen Dateien im Arbeitsspeicher, damit es nicht jedes Mal von der Festplatte lesen muss. Diese Kopie im Arbeitsspeicher wird als Seiten-Cache. Bestimmte Kernel-Funktionen wie splice() Diese zwischengespeicherten Daten werden ohne Kopieren an den Netzwerkcode übergeben, indem stattdessen ein Zeiger auf den Speicherort der Daten übergeben wird. Das spart Arbeit, solange jeder nachfolgende Schritt weiß, dass es sich um gemeinsam genutzten Speicher handelt, und nicht in diesen schreibt.

Der Fehler trat an zwei verschiedenen Stellen im Netzwerkcode des Kernels auf. Eine davon war ESP, das den verschlüsselten VPN-Datenverkehr verarbeitet. Die andere war RxRPC, ein älteres Protokoll, das hauptsächlich vom AFS-Dateisystem verwendet wird. Weder ESP noch RxRPC prüfen vor dem Schreiben, ob der Speicher gemeinsam genutzt wird.

Dadurch konnte ein Angreifer eine schreibgeschützte Datei nutzen, die ihm bei Manipulation Berechtigungen verschaffen konnte, etwa so wie /usr/bin/su, und den Inhalt in den Netzwerkpfad einspeisen, sodass die fehlerhafte Entschlüsselung letztendlich in den Speicher dieser Datei schreibt. Der Schreibvorgang landet im Seitencache, also der Kopie der Datei, die das System jedem bereitstellt, der sie liest. Die Datei auf der Festplatte ändert sich nie, aber die Version im Speicher enthält nun genau das, was der Angreifer ihr aufgezwungen hat. Der Befehl „su“ liest die manipulierte Kopie und gewährt dem Angreifer Root-Zugriff, obwohl dieser ursprünglich nur Lesezugriff auf diese Datei hatte.

„Fragnesia“, registriert unter der Kennung CVE-2026-46300, ist die spätere Variante. Durch den „Dirty Frag“-Fix verließ sich der Kernel auf einen Marker, der besagt: „Dieses Fragment wird gemeinsam genutzt – erstelle eine sichere Kopie, bevor du es veränderst.“ Ein alter Fehler aus dem Jahr 2013 im Code, der Paketfragmente zusammenführt, entfernt diesen Marker jedoch unbemerkt. Dreizehn Jahre lang blieb er harmlos, da nichts davon abhing. Leider war die „Dirty Frag“-Korrektur davon abhängig, was einen schlummernden Fehler zu einem neuen Weg zum Root-Zugriff machte. 

Warum ist „Dirty Frag“ für Container von Bedeutung?

Alle Container teilen sich denselben Kernel wie der Host, sodass ein gehackter „ container “ auf den anfälligen Kernel-Code zugreifen kann, sofern seine Berechtigungen dies zulassen (Einstellungen für Systemaufrufe, Namespaces und Sicherheitsrichtlinien). Forscher haben bereits funktionierende Proof-of-Concept-Exploits für Kubernetes veröffentlicht, und Ubuntu weist ausdrücklich auf das Risiko eines „ container “ hin:escape. Wenn der „ container “ auf den Kernel zugreifen kann, besteht das Risiko eines Root-Zugriffs auf den gesamten Knoten.

Sie können Teile des Angriffs abwehren, indem Sie Workloads als Nicht-Root-Benutzer ausführen, das Seccomp-Profil „RuntimeDefault“ aktivieren, eingeschränkte Pod-Richtlinien durchsetzen und nicht privilegierte Benutzernamensräume einschränken. Doch keine dieser Maßnahmen behebt die eigentliche Sicherheitslücke. Das kann nur das Kernel-Update des Anbieters.

Woran erkennt man, ob ein Host gefährdet ist?

Beginnen Sie mit dem tatsächlich laufenden Host, nicht mit der Dockerfile-Datei. Dazu helfen drei Befehle.

Führen Sie uname -r Um herauszufinden, welche Kernel-Version Sie verwenden, vergleichen Sie diese mit der korrigierten Version in der Sicherheitsmitteilung Ihrer Distribution. Vergleichen Sie sie nicht mit der Upstream-Nummer. Das Sicherheitsloch reicht bis zu Kerneln aus dem Jahr 2017 zurück, und Enterprise- sowie LTS-Distributionen wie RHEL, Ubuntu und Debian portieren den Patch auf die ältere Kernel-Version, die Sie bereits verwenden. Daher kann ein gepatchter Kernel immer noch eine Version aus früheren Jahren anzeigen. Ein vollständig gepatchter RHEL-8-Host zeigt immer noch 4.18 an, und diese Version 4.18 enthält den Fix. Überprüfen Sie dies anhand der Version des gepatchten Pakets Ihres Anbieters.

lsmod | grep -E 'esp4|esp6|rxrpc' Zeigt an, ob der anfällige Codepfad geladen ist. Ein leeres Ergebnis bedeutet nicht, dass Entwarnung gegeben ist, da diese Module bedarfsweise geladen werden. Und ein geladener Pfad ist nicht automatisch bedenklich. esp4, esp6 und rxrpc sind gewöhnliche Module, die auf einem gepatchten Kernel vollkommen sicher sind. So erhalten Sie einen Überblick über Ihre Angriffsfläche und können entscheiden, ob sich die Anwendung der Blacklist-Abwehrmaßnahme lohnt.

sysctl user.max_user_namespaces zeigt, wie zugänglich der ESP-Pfad ist. Ein Wert über Null bedeutet, dass nicht privilegierte Benutzer Namespaces erstellen können – der übliche Weg in den ESP-Pfad. Der Wert Null verschließt diese Tür, allerdings nur für ESP. Der RxRPC-Pfad benötigt keine Namespaces, daher ist der Schutz nicht lückenlos.

Überprüfen Sie den Status Ihres Anbieters. Laut Red Hat ist CVE-2026-43500 für die eigenen Produkte nicht relevant, während CVE-2026-43284 und CVE-2026-46300 Auswirkungen auf unterstützte Red Hat Enterprise Linux-Kernel und alle darauf basierenden Systeme haben. Ubuntu veröffentlicht für jede von ihm unterstützte Kernel-Reihe die genaue Version des Pakets, mit dem der Fehler behoben wurde.

Was sollten Sie überwachen?

Der Proof-of-Concept-Code ist bereits öffentlich zugänglich. Microsoft hat von begrenzten Aktivitäten in der Praxis berichtet wenn ein Angreifer seine Berechtigungen mithilfe von su, wobei jedoch darauf hingewiesen wird, dass es sich dabei möglicherweise um „Dirty Frag“ oder dessen Vorgänger „Copy Fail“ handeln könnte, da sich die beiden allein anhand der Prozessprotokolle nur schwer voneinander unterscheiden lassen.

Die realistischste Möglichkeit, dies zu erkennen, sind die Audit- und EDR-Tools, die Sie bereits einsetzen. Das Audit-Framework von Linux kann die Ausführung von Prozessen und setuid-Übergänge protokollieren – genau hier würde die verräterische Abfolge zutage treten: Eine unbekannte Binärdatei wird abgelegt und ausgeführt, unmittelbar gefolgt von su. Achten Sie darauf, ob „esp4“, „esp6“ oder „rxrpc“ etwa zur gleichen Zeit wie andere verdächtige Aktivitäten geladen werden – insbesondere auf einem Host, bei dem es keinen Grund gibt, IPsec oder AFS zu verwenden –, und ob neu abgelegte ELF-Dateien ausgeführt werden. 

Wenn Sie einen Angriff vermuten, führen Sie Ihre Integritätsprüfungen in einer vertrauenswürdigen Umgebung durch und nicht auf dem möglicherweise kompromittierten Host selbst. Und denken Sie daran, dass das Blockieren der Kernel-Module keine Änderungen am Seiten-Cache rückgängig macht, die ein Angreifer bereits vorgenommen hat.

Wo „ Aikido “ ins Bild passt

Meistens endet der Scanvorgang beim Image oder im Repo. „Dirty Frag“ befindet sich eine Ebene tiefer, nämlich im Kernel, in dem der Knoten tatsächlich hochfährt.

Aikido Das Sicherheits VM-Scan -Tool liest aus einem Cloud-Snapshot aus, was tatsächlich auf dem laufenden Host installiert ist, sodass ein anfälliges Kernel-Paket als Host-Befund angezeigt wird. Da es die Hosts zudem mit den darauf ausgeführten Workloads und Konten verknüpft, können Sie den Ausbreitungsradius erkennen, falls ein Knoten kompromittiert wird.

Für die Cloud-Hosts, die mit Aikido verbunden sind, listet VM-Scan diejenigen auf, auf denen das anfällige Kernel-Paket installiert ist, und zeigt an, welche Workloads darauf ausgeführt werden. Die Behebung erfolgt wie bisher: Patchen Sie den Kernel des Knotens und überprüfen Sie nach dem Neustart, ob der richtige Build geladen wurde.

{{cta}}

FAQ