Dirty Frag: universelle Linux-LPE-Schwachstelle (lokale Rechteausweitung)

 (openwall.com)
2 Punkte von GN⁺ 2 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Dirty Frag ist eine universelle Schwachstelle zur lokalen Rechteausweitung, mit der sich auf den wichtigsten Linux-Distributionen Root-Rechte erlangen lassen; durch einen gebrochenen Responsible-Disclosure-Zeitplan und ein gebrochenes Embargo gibt es derzeit noch keine Patches und keine CVE
  • Als Erweiterung derselben Bug-Klasse wie Dirty Pipe und Copy Fail handelt es sich um einen deterministischen Logikfehler, der keine Race Condition benötigt und eine sehr hohe Erfolgsquote aufweist
  • Die effektive Lebensdauer der Schwachstelle beträgt rund 9 Jahre; Tests wurden auf wichtigen Distributionen wie Ubuntu, RHEL, Fedora und openSUSE abgeschlossen
  • Auch Systeme, auf denen die bestehende Copy-Fail-Gegenmaßnahme (Blacklist für algif_aead) angewendet wurde, sind weiterhin für Dirty Frag anfällig
  • Als vorläufige Gegenmaßnahme wird bis zur Bereitstellung von Distributions-Patches empfohlen, die betroffenen Module esp4, esp6 und rxrpc zu entfernen

Überblick

  • Eine Bug-Klasse, die das frag-Mitglied der sk_buff-Struktur korrumpiert, als Erweiterung derselben Bug-Klasse, zu der Dirty Pipe und Copy Fail gehören
  • Durch das Verketten der Schwachstellen xfrm-ESP Page-Cache Write und RxRPC Page-Cache Write lässt sich auf den wichtigsten Linux-Distributionen Root-Zugriff erlangen
  • Als deterministischer Logikfehler hängt sie nicht von Timing-Fenstern ab und benötigt keine Race Condition
  • Selbst wenn ein Exploit fehlschlägt, tritt kein Kernel Panic auf, und die Erfolgsquote ist sehr hoch

Warum zwei Schwachstellen verkettet wurden

  • xfrm-ESP Page-Cache Write bietet ähnlich wie Copy Fail eine starke beliebige 4-Byte-STORE-Primitiv und ist in den meisten Distributionen enthalten, erfordert jedoch die Berechtigung zur Erstellung von Namespaces
  • Unter Ubuntu kann die Erstellung nicht privilegierter User-Namespaces durch AppArmor-Richtlinien blockiert sein; in dieser Umgebung lässt sich xfrm-ESP Page-Cache Write daher nicht auslösen
  • RxRPC Page-Cache Write benötigt keine Berechtigung zur Namespace-Erstellung, aber das Modul rxrpc.ko ist in den meisten Distributionen selbst nicht enthalten
    • Unter Ubuntu wird das Modul rxrpc.ko jedoch standardmäßig geladen
  • Durch das Verketten beider Schwachstellen werden ihre jeweiligen blinden Flecken gegenseitig ausgeglichen, sodass sich auf allen wichtigen Distributionen Root-Rechte erlangen lassen

Beziehung zu Copy Fail

  • Copy Fail war die Motivation, diese Forschung zu beginnen
  • xfrm-ESP Page-Cache Write verwendet dasselbe Sink wie Copy Fail, kann jedoch unabhängig von der Verfügbarkeit des Moduls algif_aead ausgelöst werden
  • Auch Systeme, auf denen die veröffentlichte Copy-Fail-Gegenmaßnahme (Blacklist für algif_aead) angewendet wurde, bleiben für Dirty Frag anfällig

Betroffener Umfang

  • xfrm-ESP Page-Cache Write: ab Commit cac2661c53f3 (2017-01-17) bis Upstream
  • RxRPC Page-Cache Write: ab Commit 2dc334f1a63a (2023-06) bis Upstream
  • Die effektive Lebensdauer der Schwachstelle beträgt rund 9 Jahre
  • Getestete Distributionsversionen:
    • Ubuntu 24.04.4: 6.17.0-23-generic
    • RHEL 10.1: 6.12.0-124.49.1.el10_1.x86_64
    • openSUSE Tumbleweed: 7.0.2-1-default
    • CentOS Stream 10: 6.12.0-224.el10.x86_64
    • AlmaLinux 10: 6.12.0-124.52.3.el10_1.x86_64
    • Fedora 44: 6.19.14-300.fc44.x86_64

Gegenmaßnahmen

  • Durch den gebrochenen Responsible-Disclosure-Zeitplan und das gebrochene Embargo existieren derzeit für keine Distribution Patches
  • Als temporäre Gegenmaßnahme wird ein Befehl zum Entfernen der betroffenen Module angegeben: 
    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"
    • Trägt die Module esp4, esp6 und rxrpc in /etc/modprobe.d/dirtyfrag.conf als Blacklist ein und entlädt sie
  • Nachdem die einzelnen Distributionen Patches backportiert haben, müssen diese Updates eingespielt werden

Hintergrund der Veröffentlichung

  • Das Dirty-Frag-Dokument wurde nach Abstimmung mit den Maintainer:innen von linux-distros@vs.openwall.org auf deren Bitte hin veröffentlicht
  • Das Embargo ist durch externe Faktoren gebrochen, und aktuell gibt es weder Patches noch eine CVE
  • Das PoC wurde nach Abstimmung mit linux-distros zum Zweck einer präzisen Informationsbereitstellung veröffentlicht; die Nutzung auf nicht autorisierten Systemen ist untersagt

Verwandte Beiträge

2 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Das ist in der Grundursache und der Art der Ausnutzung Copy Fail sehr ähnlich.
    Für mich ist das ein gutes Beispiel für etwas, das man leicht verliert, wenn man LLMs zu viel Arbeit überlässt: Exploration. Bei der KI-gestützten Schwachstellenforschung fühlt es sich an, als würde Kreativität ziemlich gehemmt. Wenn auf eine Frage sofort eine Antwort kommt, sieht man nicht, was sonst noch in der Umgebung liegt. Es ist wie ein Genie, das genau das liefert, worum man gebeten hat, und nichts darüber hinaus.
    Der Forscher, der Copy Fail gefunden hat, hat sich nach etwas Verdächtigem stark auf KI verlassen; hätte er selbst viel mehr Code durchwühlt, hätte er mehr Chancen gehabt, solche Zwillings-Bugs zu finden. Gleichzeitig glaube ich, dass aktuelle LLMs diese Bugs wohl gefunden hätten, wenn man den Prompt etwas weniger direktiv formuliert hätte. Ein ziemlich ungewöhnlicher Fall von negativer Synergie: zusammen gearbeitet, aber mit schlechterem Ergebnis

    • Wenn ich es nicht falsch gelesen habe, ist es nicht nur ähnlich, sondern dieselbe Grundursache. Es geht um die oberen 32 Bit des Extended ESN von IPsec == ein Problem im Modul/Auth-Cipher-Modus authencesn.
      Bei copy.fail wurde das Falsche gefixt, und die Leute haben vorschnell AF_ALG die Schuld gegeben.
      [Bearbeitung: Ja, korrekt, es ist dasselbe authencesn-Problem. Im Code https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... wird authencesn zwar nur in Kommentaren erwähnt, aber es ist trotzdem dasselbe Problem.]
      [Bearbeitung2: Das RxRPC-Problem ist separat; hier geht es um die ESP-Seite.]
    • Man könnte als Folgeprompt auch sagen: „Finde Bugs ähnlicher Art.“ Sobald ein konkreter Fall einmal aufgearbeitet ist, ist es nicht besonders schwer, ähnliche Bugs zu finden.
      Ich verstehe den Punkt mit der Kreativität. Wie jedes Werkzeug kann KI den Blick verengen. Es ist schwer, sie nur unterstützend zu nutzen und ihr nicht den gesamten Workflow zu überlassen.
    • Ich verstehe das nicht. Diese Bugs wurden doch überhaupt erst von LLMs gefunden. Trotzdem klingt das hier so, als sei diese Entdeckung ein Zeichen dafür, dass LLMs schlecht für die Schwachstellensuche seien.
    • Ich frage mich, ob das eine belastbare Aussage ist oder nur spontan dahinassoziiert.
    • Es ist sehr schwer, aus einer KI-gefundenen Grundschwachstelle, die ähnlich, aber nicht völlig identisch ist, die Lehre abzuleiten, KI könne nicht explorieren.
      Außer in dem Fall, dass beide Schwachstellen zusammen offengelegt worden wären: In welchem kontrafaktischen Szenario würde man sagen, hier wurde „gut genug exploriert“?

  • „Es gibt keine Patches oder CVEs für diese Schwachstellen, weil das Embargo gebrochen wurde.“
    Link: https://github.com/V4bel/dirtyfrag
    Detaillierte Analyse: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
    Der wichtige Teil ist dieser: „Copy Fail war die Motivation, diese Forschung zu beginnen. Insbesondere teilt der xfrm-ESP Page-Cache-Write in der Dirty-Frag-Schwachstellenkette denselben Sink wie Copy Fail. Er wird jedoch unabhängig davon ausgelöst, ob das Modul algif_aead verwendbar ist. Mit anderen Worten: Selbst auf Systemen, auf denen die öffentlich bekannte Copy-Fail-Abschwächung durch Blacklisting von algif_aead angewendet wurde, bleibt Linux weiterhin für Dirty Frag verwundbar.“
    Die Abschwächung soll wie folgt aussehen, ich habe sie aber nicht selbst getestet oder verifiziert: „Wegen des gebrochenen Zeitplans für Responsible Disclosure und des Embargos gibt es in keiner Distribution einen Patch. Entferne die Module, die die Schwachstelle auslösen, mit dem folgenden Befehl“
    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"
    In Gesprächen zur Abschwächung hieß es, ein Neustart sei erforderlich oder dass man auf einer bereits ausgenutzten Maschine nach dem obigen Befehl Folgendes ausführen müsse: sudo echo 3 > /prox/sys/vm/drop_caches

    • Bei sudo echo 3 > /prox/sys/vm/drop_caches hat sudo keine Wirkung. sudo führt nur echo aus; der eigentliche Schreibzugriff passiert nicht darüber.
      Und wenn die Maschine bereits ausgenutzt wurde, ist es dafür ohnehin zu spät. Alles auf der Platte könnte beschädigt sein; man müsste das gesamte Disk-Image neu erstellen.
    • In einer Nicht-sudo-Shell kann man sudo echo und Redirect so nicht verwenden.
      echo 3 | sudo tee /proc/sys/vm/drop_caches
      oder
      sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
      Und ich habe auch den Tippfehler bei /proc korrigiert.
    • Zur Info: Mit echo 1 > ... kann man ebenfalls mitigieren. Man muss nicht alles leeren; es reicht, mit 1 nur den Page Cache zu verwerfen.
      Lokal auf Ubuntu 26.04 getestet: Exploit ausgeführt und root erhalten, dann die Mitigation gesetzt und su ohne Argumente erneut ausgeführt — sofort wieder root ohne Passwort. Danach den Page Cache geleert, und su verlangte ein Passwort.

  • Wir brauchen einen einfachen Weg sicherzustellen, dass nur Kernel-Module von einer Whitelist geladen werden. Ich bin es leid, ständig weitere unnötige Module auf Blacklists zu setzen.

  • Ich frage noch einmal: Warum bekommt bei copy.fail eigentlich algif_aead den ganzen Hass ab? Dumm ist authencesn.
    authencesn wurde nicht gefixt, und jetzt sieht man das Ergebnis. Es zeigt sich, dass man über normale Netzwerk-Sockets auf denselben, vermutlich denselben Out-of-Bounds-Write zugreifen kann.
    Das hätte mir einfallen sollen, ist es aber nicht.
    [Bearbeitung: Ich meine das Problem über ESP. Das RxRPC-Problem ist nach meinem Verständnis etwas völlig anderes.]

  • Wenn das wirklich auf allen großen Distributionen funktioniert, überrascht mich die Verantwortungslosigkeit der Maintainer immer wieder. Warum sind optionale Kernel-Funktionen standardmäßig aktiviert, die vermutlich nicht einmal für 0,1 % der Nutzer nützlich sind?
    Das erinnert an Linux-Distributionen von 1999, die in einer Standardinstallation Dutzende ans Internet exponierte Netzwerkdienste mitlieferten. Aber wir haben nicht mehr 1999.

    • Es ist schon eine große Forderung, wenn Distribution-Maintainer bestimmte Funktionen auf Basis von „du wirst das vermutlich nicht brauchen“ (YAGNI) auf Blacklists setzen sollen. Sie können nicht wissen, wer was nutzt. Nutzer können jederzeit zurückgehen und den Build an das anpassen, was sie tatsächlich wollen.
      Ich erinnere mich an die frühen Linux-Zeiten, als man make menuconfig ausführte und exakt auswählte, welche Funktionen man im Kernel haben wollte. Ehrlich gesagt möchte ich nicht dorthin zurück.
      Ein Bereich, den man hier aber leicht verbessern könnte, ist RHEL. RHEL kompiliert viele Dinge direkt in den Kernel statt sie als ladbare Module zu belassen, wodurch Mitigations wie bei copy fail unmöglich wurden. Vielleicht ließe sich das etwas reduzieren.
    • Es gibt keinen Weg, Komponenten zu deaktivieren, die der Nutzer wahrscheinlich nicht verwendet, ohne gleichzeitig die Nutzung des Systems massiv zu erschweren. Selbst ich, nach 25 Jahren mit diesem dummen OS, habe keine Möglichkeit zu wissen, was ich ein- oder ausschalten müsste, um irgendetwas zu tun.
      Linux-Distributions-Maintainer sind die verantwortungsvollsten Software-Maintainer auf der Welt. Ihre Sicherheitspraktiken sind den dummen Paketmanagern von Programmiersprachen weit überlegen; sie pflegen kuratierte Paketlisten, prüfen Änderungen, patchen Bugs, lösen komplexe Packaging-Probleme, backporten Fixes, nutzen gestaffelte Releases, verteilen Dateien über weltweite Mirror und verifizieren alle Dateien kryptografisch. Und man sollte nicht vergessen, dass sie all das kostenlos tun.
    • Es ist nicht standardmäßig aktiviert. Es sind optionale Module, die bei Bedarf geladen werden. Die gesamte Architektur des Kernels ist darauf ausgelegt, die zentralen Funktionen, die der Nutzer braucht, einzukompilieren und fast alles andere als Module bereitzustellen, die bei Bedarf geladen werden.
    • In vielerlei Hinsicht sind Computer, die keine Mobilgeräte sind, immer noch im Jahr 1999. Android ist deutlich jünger und hatte die Chance, Mandatory Access Control in den gesamten Stack zu integrieren; deshalb ist es wesentlich sicherer als andere Linux-Systeme.
    • Um das auszunutzen, muss man physischen Zugriff auf den Computer haben. Es müsste also ein bösartiges USB-Gerät sein, ein Supply-Chain-Angriff oder das Ausnutzen bekannter Software, die der Nutzer willentlich oder automatisch installiert. Darüber hinaus muss man praktisch beliebige Terminal-Befehle ausführen können, was innerhalb der Isolation dieser Software bereits ein massiver Kompromiss wäre.
      Wenn ein Angreifer all das schon geschafft hat, ist die Lage ohnehin bereits schlecht. Dass er damit noch zu root eskaliert, ist ab diesem Punkt eine der kleineren Sorgen.
      Wie jemand weiter unten gepostet hat: https://xkcd.com/1200/
      Bevor Leute in Panik geraten, sollte man verstehen, was diese Schwachstelle tatsächlich ist.

  • Nach all den Jahren haben wir endlich den Punkt erreicht, an dem „given enough eyeballs, all bugs are shallow“ gilt, und irgendwie ist das unerquicklich. Müssen wir ab jetzt mehrmals pro Woche Kernel-Updates machen?

    • Glaubst du, dass jemand in dein Haus einbricht, irgendwie deine Standardzugangsdaten findet und sich dann auch noch root-Zugriff verschafft?

  • Ich frage mich, wie das Embargo gebrochen wurde. War es ein Leak, oder hat es ein Dritter unabhängig gefunden?

    • Ein Embargo existiert überhaupt nicht und kann auch nicht existieren.
      Linux ist Open Source, also sind alle Patches, die Sicherheitsbugs beheben, sofort für alle sichtbar. Es gibt aufgrund der Arbeitsweise der Kernel-Entwicklung keinen Weg, das zu umgehen. Was Leute „Embargo“ nennen, ist die ziemlich dumme Vorstellung, dass man so tun kann, als sei eine Schwachstelle nicht geleakt, solange man in der Patch-Beschreibung nicht ausdrücklich „THIS IS A LPE“ hineinschreibt und stillhält, bis eine „offizielle“ Nachricht auf der Mailingliste erscheint.
      Früher ließ sich dieser Ansatz vielleicht noch halbwegs verteidigen, aber im Zeitalter der LLMs ist er nicht nur dumm, sondern gefährlich, weil man die Diffs der Mailingliste automatisiert an aktuelle Modelle verfüttern und sie identifizieren lassen kann, ob ein Patch ein Sicherheitsproblem behebt.
    • Der Link zum Patch wurde auf dem X-Account von jemandem gepostet, und jemand anders hat ihn gesehen und weniger als eine Stunde später einen funktionierenden Exploit veröffentlicht. Es könnte mit LLMs passiert sein, aber außer der schnellen Turnaround-Zeit ist das nicht belegt.
      https://x.com/encrypted_past/status/2052409822998392962
    • Ein nicht beteiligter Dritter hat es öffentlich gepostet.

  • Weiß jemand, ob Debian verwundbar ist? Ich habe den Exploit auf Debian-12- und Debian-13-Maschinen versucht, konnte ihn aber nicht selbst reproduzieren.

    • Ich konnte es auf Debian 13, also Trixie, mit dem Kernel 6.12.57+deb13-amd64 reproduzieren, aber nicht auf Debian 12 Bookworm mit dem Kernel 6.1.0-42-amd64.
      Für Leute auf Bookworm, die nicht den Debian-Paket-Sicherheits-Stream verwenden, ist der Kernel 6.1.0-42-amd64 tatsächlich gegen copy.fail immun. Überraschend ist, dass er anscheinend auch gegen dirtyfrag immun ist. Wenn der Sicherheits-Stream es noch nicht gepatcht hat, könnte man eine Kernel-Version wählen, die Commit 2b8bbc64b5c2 beibehält. Ich vermute, dass genau dieses Commit einige Debian-12-Kernel-Versionen zufällig auch gegen dirtyfrag sicher macht.
    • Ich habe es gerade auf einem frischen Debian-13-Droplet von DigitalOcean versucht, und dort hat es funktioniert.
    • Ich habe es auf einem vollständig aktuellen Debian 13 getestet, und der Exploit funktioniert. Ich habe auch bestätigt, dass die Mitigation funktioniert.

  • Ausgeführt in einem ubuntu:latest-Container als neuer Standardnutzer
    git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
    Ergebnis: dirtyfrag: failed (rc=3)
    Gute Nachrichten!

    • Bei mir kam im Container dasselbe Ergebnis heraus, aber direkt auf dem Host bekam ich eine Shell. Das zeigt nur, dass der Exploit im Container nicht funktioniert. Daraus folgt entweder, dass der Container nicht verwundbar ist, oder dass das Skript angepasst werden müsste, damit es im Container funktioniert.
      copy fail kann für Container-Escape genutzt werden (https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), daher vermute ich, dass beim Exploit nur kleine Änderungen nötig wären.
    • Container sind kaum eine verlässliche Plattform für solche Tests. Ob beabsichtigt oder nicht: Es gibt viele Dinge, die in Containern fehlschlagen.
 
GN⁺ 2 시간 전
Lobste.rs-Kommentare

  • Es war wirklich eine bemerkenswerte Woche, um gemeinsam genutzte Linux-Server zu verwalten. Immerhin gefällt mir an dieser Veröffentlichung, dass sie direkt zur Sache kommt
    Allerdings verstehe ich nicht, warum in den Mitigation-Anleitungen alle stderr ausblenden
    Edit: Das wurde wohl am 30. April gemeldet, inspiriert von copy.fail – wurde es also in weniger als einem Tag entdeckt? Beeindruckend
    Als jemand mit sudo-Rechten auf einem ziemlich großen Shared Server frage ich mich auch, ob es vielleicht eine gute Idee wäre, den Kernel selbst zu kompilieren und dabei möglichst wenige Module einzubinden. Ich habe die Vor- und Nachteile nicht gründlich abgewogen, aber es wirkt, als hätte man damit beide lokalen Privilege-Escalation-Lücken dieser Woche vermeiden können
    Edit 2:

     * 2. rxrpc path  (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
 *    path can't reach the page cache, fall back to the rxrpc/rxkad
 *    nullok primitive that patches /etc/passwd's root entry empty.
 *    PAM nullok then accepts the empty password during `su -`.

    Oh, dafür ist kein setuid nötig. Gut, dass das enthalten ist

    • Ich mache das auf einem Mehrbenutzersystem, das ich betreue, und konnte dadurch die beiden lokalen Root-Exploits dieser Woche tatsächlich vermeiden

  • Wäre es möglich und sinnvoll, die Liste der auf einem laufenden System geladenen Kernel-Module zu übernehmen und sie als modprobe-Allowlist für dieses System zu setzen?
    Sowohl CopyFail als auch DirtyFrag scheinen Kernel-Module auszunutzen, die auf keinem der Systeme, die ich überprüft habe, geladen waren. Wenn das so ist, könnte das Blockieren von Modulen, die offensichtlich nicht gebraucht werden, einige Angriffe vielleicht im Voraus abmildern?

  • 2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
    Ich verstehe nicht, wie so etwas zugelassen werden kann. Dass Informationen in dieser Größenordnung in einer derart schwer vertrauenswürdigen Umgebung landen, wirkt einfach völlig absurd

    • Ich bin nicht sicher, ob mit „unrelated third party published“ dieser Fall gemeint ist, aber der Vollständigkeit halber: Brad Spengler sah zuerst den Fix-Commit und erkannte anhand der von der Commit-Message angedeuteten Sicherheitslücke das Problem, und in den Antworten hat dann jemand per Vibe Coding einen Exploit gebaut
      Jeder Dritte, der Linux-Commits beobachtet hat, hätte vermutlich dieselben Hinweise aufgreifen und einen Exploit bauen können
    • Die Formulierung „unrelated third party“ klingt so, als bedeute sie, dass diese Person nicht wusste, dass der Bug unter Embargo stand
      Die „schwer vertrauenswürdige Umgebung“ ist hier das gesamte Internet, und etwas, das man wirklich als isoliert bezeichnen könnte, gibt es kaum. Das war schon immer so, nur ist es inzwischen noch offensichtlicher geworden. Dazu passt auch Stefan Eissings jüngster Beitrag darüber, wie ein Apache-httpd-Bug zweimal wiederentdeckt wurde, bevor er gefixt war

  • Gibt es eine Möglichkeit zu testen, ob die betroffenen Module wirklich nicht geladen werden können?
    Bei CopyFail habe ich beim ersten Anwenden der Mitigation einen Fehler gemacht. Der Dateiname in /etc/modprobe.d/ endete nicht auf .conf, und ich habe das erst bemerkt, nachdem ich den Testbefehl von https://news.ycombinator.com/item?id=47954159 ausgeführt hatte. Gibt es für die Module esp4/esp6/rxrpc einen ähnlichen Befehl?

    • Ich habe alle drei Module mit modprobe zu laden versucht, und es kam derselbe Fehler wie beim letzten Mal
      Es gibt auch angehängten Proof-of-Concept-Code, aber ich habe ihn noch nicht ausprobiert