Misty-Schleier-Warnung: Hochkritische Linux-Privilege-Escalation-Lücke, drei Module umgehend deaktivieren

Der Chief Information Security Officer von SlowMist, 23pds, hat am 8. Mai offengelegt, dass es im Linux-System eine schwerwiegende Privilege-Escalation-Schwachstelle namens Dirty Frag gibt. Vollständige Details und Exploit-Code wurden veröffentlicht. Jeder lokale Low-Privilege-User kann die Root-Administratorrechte des betroffenen Systems direkt erlangen, ohne spezielle Systembedingungen erfüllen zu müssen. Die dringende Notfallmaßnahme besteht darin, die drei Module esp4, esp6 und rxrpc zu deaktivieren.

Warum Dirty Frag so gefährlich ist: Logikfehler, hohe Erfolgsquote, ohne Patch

Dirty Frag ist eine deterministische Logikschwachstelle und keine instabile Attacke, die von Race-Conditions abhängt. Das macht die Erfolgsquote extrem hoch und eine zuverlässige Reproduktion ist möglich. Angreifer müssen nur ein kleines Programm ausführen, um sofort Root-Rechte auf dem Zielsystem zu erhalten. Der gesamte Prozess führt nicht zum Absturz des Kernels und ist nur sehr schwer über herkömmliche Überwachungsmechanismen zu erkennen.

Die Schwachstelle wurde am 30. April von Sicherheitsforschern an das Linux-Kernteam übermittelt, jedoch bevor die Reparaturarbeiten abgeschlossen waren, wurden detaillierte Informationen und Exploit-Code von einem „unbeteiligten Dritten“ vorzeitig geleakt. Dadurch wurde die Sicherheitsanordnung gezwungen aufgehoben. Die Sicherheitscommunity geht allgemein davon aus, dass dies bedeutet, dass ein böswilliger Angreifer die Schwachstelle möglicherweise bereits aktiv ausnutzt.

Aus technischer Sicht ist Dirty Frag in seinem Mechanismus ähnlich zu der Copy-Fail-Schwachstelle, die derzeit in der Linux-Serverlandschaft weit verbreitete Schäden verursacht. In beiden Fällen wird der Angriff durch das Einfügen von Page-Cache-Descriptoren in eine Zero-Copy-Operation umgesetzt. Die zugrunde liegende Schwachstelle „xfrm-ESP Page-Cache Write“ wurde durch einen Kernel-Commit aus dem Jahr 2017 mit der Kennung cac2661c53f3 eingeführt. Da der AppArmor-Fix von Ubuntu diese Schwachstelle abdeckte, verknüpfte der PoC die zweite Schwachstelle „RxRPC Page-Cache Write“ (Commit 2dc334f1a63a), um sicherzustellen, dass der Angriff auf Ubuntu-Systemen ebenfalls wirksam ist.

Betroffener Umfang: bestätigte Liste gängiger Linux-Distributionen

Bestätigt betroffene Linux-Distributionen (teilweise):

· Ubuntu 24 und Ubuntu 26 (inklusive AppArmor, über die zweite Schwachstelle umgangen)

· Arch Linux (auch aktualisierte Versionen wurden bestätigt)

· RHEL (Red Hat Enterprise Linux)

· OpenSUSE

· CentOS Stream

· Fedora

· AlmaLinux

· CachyOS (Kernel-Version 7.0.3-1-cachyos wurde als auslösend bestätigt)

· WSL2 (Windows Subsystem for Linux) wurde ebenfalls als betroffen bestätigt

Dringende Notfallmaßnahmen: konkrete Befehle zum Deaktivieren der drei Module

Vor der Veröffentlichung offizieller Patches ist die effektivste Maßnahme das Deaktivieren der drei Module esp4, esp6 und rxrpc. Diese drei Module stehen alle im Zusammenhang mit der IPSec-Netzwerkfunktion. Wenn der Server selbst kein IPSec-Client oder -Server ist (also für Verschlüsselungskommunikation auf Netzwerkebene genutzt wird), hat das Deaktivieren nach dem aktuellen Stand nahezu keine Auswirkungen auf den normalen Betrieb.

Mit den folgenden Befehlen können die Module deaktiviert werden: 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”

Bitte verfolgen Sie nach Abschluss der Ausführung die Sicherheitsmeldungen der jeweiligen Linux-Distributionen genau. Führen Sie Systemaktualisierungen unmittelbar nach der offiziellen Veröffentlichung der Patches durch.

Häufige Fragen

Gibt es für die Dirty Frag-Schwachstelle aktuell bereits einen offiziellen Patch?

Bis heute hat der Hersteller noch keinen Patch veröffentlicht, und auch im Linux-Mainline-Kernel wurde kein Fix-Commit gefunden. Das liegt daran, dass die Sicherheitsanordnung bereits vor Abschluss der Patch-Vorbereitungen gebrochen wurde, wodurch die Details der Schwachstelle veröffentlicht wurden, bevor die Reparaturarbeiten abgeschlossen waren. Systemadministratoren sollten die Sicherheitsmeldungen der Linux-Distributionen genau verfolgen und nach Veröffentlichung der Patches umgehend bereitstellen.

Beeinflusst das Deaktivieren der Module esp4, esp6 und rxrpc den normalen Serverbetrieb?

Diese drei Module stehen hauptsächlich mit IPSec-Protokollen in Verbindung. Wenn der Server selbst kein IPSec-Client oder -Server ist (also für verschlüsselte Kommunikation auf Netzwerkebene), dann beeinträchtigt das Deaktivieren dieser Module nahezu keinen regulären Betrieb wie Web-Services, Datenbanken oder verschlüsselte Knoten. Das ist derzeit die sicherste Notfallmaßnahme mit den geringsten Auswirkungen.

Warum wurde diese Schwachstelle ohne Patch veröffentlicht?

In der Branche gilt das übliche Vorgehen der „verantwortungsvollen Offenlegung“: Sicherheitsforscher warten nach der Einreichung einer Schwachstelle beim Hersteller normalerweise, bis der Patch fertig ist, bevor sie Details veröffentlichen. Diese Schwachstelle wurde am 30. April eingereicht, aber ein „unbeteiligter Dritter“ leakte die detaillierten Informationen vorzeitig und brach damit die Anordnung. Sicherheitsforscher vermuten, dass ein böswilliger Angreifer die Schwachstelle möglicherweise bereits aktiv ausnutzt, was auch der Auslöser dafür war, dass die Anordnung schließlich aufgehoben wurde.