Keiner der beiden Bugs ist für sich allein vollständig zuverlässig — der ESP-Pfad erfordert die Fähigkeit, einen User Namespace zu erstellen (was Ubuntus AppArmor blockiert), und der RxRPC-Pfad benötigt rxrpc.ko geladen (was die meisten Distributionen standardmäßig nicht tun). Zusammen decken sie die blinden Flecken des jeweils anderen ab, wodurch die Kette auf praktisch jeder großen Distribution funktioniert.

Ein öffentlicher Proof-of-Concept ist verfügbar. Geh davon aus, dass er bereits aktiv genutzt wird.

Was dieses Skript tut

Es prüft dein System auf die Bedingungen, die eine Ausnutzung möglich machen, und sagt dir konkret, warum du exponiert bist — nicht nur ein Ja oder Nein.

Es wird nichts reparieren. Es wird nichts ausnutzen. Es sagt dir nur die Wahrheit über dein System.

Voraussetzungen

• Python 3.6+
• Keine externen Abhängigkeiten — nur stdlib
• Kein Root erforderlich (bewusst — wir prüfen, was ein unprivilegierter Angreifer sehen kann)

Verwendung

Das war's. Farbcodierte Ausgabe, konkrete Gründe für jeden Befund und eine Zusammenfassung zur Behebung am Ende.

Screenshot

[]

Behebung

Der eigentliche Fix ist das Patchen deines Kernels. Prüfe die Sicherheitshinweise deiner Distribution:

Während du wartest (oder falls für deine Distribution noch keine Patches verfügbar sind), blockiere die verwundbaren Module:

⚠️ Bevor du das tust:

• Das Blockieren von esp4/esp6 bricht IPsec-Tunnel (strongSwan, Libreswan; WireGuard ist nicht betroffen). Wende das nicht auf VPN-Gateways an.
• Das Blockieren von rxrpc bricht AFS-Clients für verteilte Dateisysteme. Fast niemand nutzt das — aber prüfe zuerst.

Wichtig: Falls dein System vor der Anwendung der Mitigation Ziel eines Angriffs gewesen sein könnte, kann der Exploit Binärdateien im Page Cache verändern, ohne die Festplatte zu berühren. Dateiintegritätstools (Tripwire, AIDE), die On-Disk-Checksummen prüfen, werden nichts Falsches sehen. Ein Neustart leert den Page Cache und stellt den On-Disk-Zustand wieder her.

So funktioniert es (die Kurzversion)

Beide Bugs liegen in den In-Place-Entschlüsselungs-Schnellpfaden des Kernels. Wenn ein Socket-Puffer Seitenfragmente trägt, die nicht privat dem Kernel gehören — zum Beispiel Pipe-Seiten, die über splice() oder sendfile() angehängt wurden — entschlüsseln die ESP- und RxRPC-Empfangspfade direkt über diese extern hinterlegten Seiten, statt zuerst zu kopieren.

Ein Angreifer kann eine Seite aus dem Cache von /usr/bin/su (oder einer anderen lesbaren Datei) in einen dieser Entschlüsselungspfade lenken und dabei seinen eigenen Schlüssel verwenden, sodass die „entschlüsselte Ausgabe" genau die Bytes sind, die er wählt. Der Kernel schreibt diese Bytes direkt in die In-Memory-Cache-Kopie von su. Die Datei auf der Festplatte bleibt unberührt. Der Kernel markiert die Seite nie als dirty.

Ab diesem Zeitpunkt führt jeder Prozess, der su ausführt, die Version des Angreifers aus — bis drop_caches oder ein Neustart.

Die ESP-Variante (cac2661c53f3) und die RxRPC-Variante (2dc334f1a63a) teilen sich dieselbe Senke, haben aber unterschiedliche Voraussetzungen, die sich gegenseitig aufheben, wodurch die Kette über alle großen Konfigurationen hinweg zuverlässig ist.

Für die vollständige technische Ausarbeitung siehe V4bel/dirtyfrag.

Offenlegungs-Zeitplan

Danksagung: Hyunwoo Kim (@v4bel) für die ursprüngliche Forschung, Offenlegung und den PoC.

Haftungsausschluss

Nur zur Erkennung. Richte es auf Systeme, die du autorisiert bist zu bewerten.