[English]Sicherheitsforscher von Qualys TRU haben zwei verknüpfte, kritische Schwachstellen in Linux aufgedeckt. Ausgehend von SUSE 15 führt die LPE-Kette bei Standardkonfigurationen vieler Linux-Distributionen direkt zum Root-Zugriff.
Qualys TRU (Threat Research Unit), die Forschungsabteilung von Qualys, Inc. (Anbieter von Cloud-basierten IT-, Sicherheits- und Compliance-Lösungen), hat zwei eng miteinander verknüpfte Schwachstellen (CVE-2025-6018 und CVE-2025-6019) entdeckt.
- CVE-2025-6018: LPE from unprivileged to allow_active in *SUSE 15's PAM
- CVE-2025-6019: LPE from allow_active to root in libblockdev via udisks
Deren Kombination ermöglicht es Angreifern, Root-Zugriff auf Linux-Systeme mit Standardkonfiguration zu erlangen.
Details zu den Schwachstellen
Die erste Schwachstelle (CVE-2025-6018) befindet sich in der PAM-Konfiguration von openSUSE Leap 15 und SUSE Linux Enterprise 15. Ein nicht privilegierter lokaler Nutzer, beispielsweise über eine SSH-Verbindung, kann diese Schwachstelle ausnutzen, um sich den Status eines "allow_active"-Nutzers zu verschaffen und anschließend polkit-Aktionen auszuführen, die normalerweise nur physisch anwesenden Nutzern vorbehalten sind.
Die zweite Schwachstelle (CVE-2025-6019) betrifft libblockdev, lässt sich über den udisks-Daemon ausnutzen, der in den meisten Linux-Distributionen standardmäßig enthalten ist, und ermöglicht es einem "allow_active"-Nutzer, vollständige Root-Rechte zu erlangen. Während CVE-2025-6019 für sich allein genommen den vorhandenen "allow_active"-Status voraussetzt, kann durch die Kombination mit CVE-2025-6018 selbst ein vollständig unprivilegierter Angreifer Root-Zugriff erlangen.
Die Schwachstelle in libblockdev/udisks ist von besonderer Relevanz. Zwar erfordert sie nominell den Status "allow_active", jedoch ist der udisks-Daemon auf nahezu allen Linux-Distributionen standardmäßig installiert, wodurch fast alle Systeme potenziell angreifbar sind. Techniken zur Erlangung des "allow_active"-Status, einschließlich der hier beschriebenen PAM-Schwachstelle, beseitigen diese Hürde faktisch. Ein Angreifer kann beide Schwachstellen kombinieren und mit minimalem Aufwand Root-Zugriff erlangen. Aufgrund der weiten Verbreitung von udisks und der einfachen Ausnutzbarkeit dieser Angriffskette sollten Unternehmen diese Bedrohung als kritisch und universell einstufen und die verfügbaren Sicherheitsupdates umgehend einspielen.
Die Qualys Threat Research Unit (TRU) hat Proof-of-Concept-Exploits entwickelt, um diese Schwachstellen auf verschiedenen Betriebssystemen zu validieren. Dabei konnte die libblockdev/udisks-Schwachstelle erfolgreich auf Ubuntu, Debian, Fedora und openSUSE Leap 15 ausgenutzt werden.
Funktionsweise von PAM und udisks/libblockdev
PAM-Konfiguration in openSUSE/SLE 15: Das Pluggable Authentication Modules (PAM) Framework steuert, wie sich Nutzer auf Linux-Systemen authentifizieren und Sitzungen starten. In openSUSE/SLE 15 ist der PAM-Stack so konfiguriert, dass er bestimmt, welche Nutzer als "aktiv" gelten — also physisch am System anwesend — und damit bestimmte privilegierte Aktionen ausführen dürfen. Eine Fehlkonfiguration kann dazu führen, dass jede lokale Anmeldung, einschließlich über SSH, so behandelt wird, als säße der Nutzer direkt an der Konsole. Dieser "allow_active"-Status erlaubt normalerweise Zugriff auf bestimmte polkit-Operationen, die physisch anwesenden Nutzern vorbehalten sind. Wird dieser Mechanismus falsch angewendet, können nicht privilegierte Nutzer Aktionen ausführen, die ihnen eigentlich nicht gestattet sein sollten.
udisks-Daemon und libblockdev: Der udisks-Dienst läuft standardmäßig auf den meisten Linux-Systemen und bietet über D-Bus eine Schnittstelle zur Speicherverwaltung — darunter das Mounten, Abfragen und Formatieren von Datenträgern. Intern greift udisks auf libblockdev zu, eine Bibliothek zur Verarbeitung von Blockgeräteoperationen auf niedriger Ebene. Eine über udisks erreichbare Schwachstelle in libblockdev ermöglicht es jedem Nutzer mit "allow_active"-Status, direkt Root-Rechte zu erlangen. Da udisks so weit verbreitet ist, ist das Verständnis seiner Funktion und der Abhängigkeit von libblockdev entscheidend. udisks fungiert dabei als Bindeglied zwischen den Sitzungsrechten eines Nutzers und den Verwaltungsfunktionen für Geräte. Eine Schwachstelle an dieser Stelle kann vollständige Systemkontrolle ermöglichen.
Mögliche Auswirkungen
Diese modernen "local-to-root"-Exploits überbrücken die Lücke zwischen einem gewöhnlichen eingeloggten Nutzer und einer vollständigen Systemübernahme. Durch das Verketten legitimer Dienste wie udisks-Loop-Mounts und Besonderheiten in der PAM- und Umgebungs-Konfiguration können Angreifer mit einer aktiven GUI- oder SSH-Sitzung die Vertrauensgrenze von polkit ("allow_active") überwinden und sich innerhalb von Sekunden Root-Rechte verschaffen. Dafür sind keine exotischen Fähigkeiten notwendig, denn alle verwendeten Komponenten sind in gängigen Linux-Distributionen und deren Server-Varianten vorinstalliert.
Root-Zugriff stellt die schwerwiegendste Art von Schwachstelle dar. Ein Angreifer kann damit unbemerkt EDR-Agenten deaktivieren, Kernel-Backdoors für persistente Codeausführung installieren oder Systemkonfigurationen manipulieren, die Neustarts überdauern. Solche kompromittierten Server können als Ausgangspunkt für laterale Bewegungen im Netzwerk dienen. Exploits, die auf standardmäßig installierte Serverpakete abzielen, können sich von einem einzelnen kompromittierten System auf ganze Flotten ausbreiten. Um dieses Risiko zu verringern, sollten systemweit Updates eingespielt und Sicherheitsmaßnahmen wie polkit-Regeln und Loop-Mount-Policies verschärft werden. Diese breit angelegte Strategie hilft, eine erste Kompromittierung einzudämmen und das gesamte Netzwerk zu schützen.
Absicherung gegen die libblockdev/udisks-Schwachstelle
Die Standard-Polkit-Richtlinie für die Aktion "org.freedesktop.udisks2.modify-device" erlaubt es möglicherweise jedem aktiven Nutzer, Geräte zu verändern. Diese Konfiguration kann ausgenutzt werden, um Sicherheitsmechanismen zu umgehen. Um dies zu verhindern, sollte die Richtlinie so angepasst werden, dass für diese Aktion eine Authentifizierung durch einen Administrator erforderlich ist.
Zur Minderung dieser Schwachstelle sollte die Polkit-Regel für "org.freedesktop.udisks2.modify-device" angepasst werden. Der Wert für "allow_active" sollte von "yes" auf "auth_admin" geändert werden. Darüber hinaus sollten stets verfügbare Sicherheitsupdates priorisiert und die konkreten Empfehlungen der jeweiligen Linux-Distribution beachtet werden.
Fazit
Durch die Kombination von CVE-2025-6018 und CVE-2025-6019 kann sich ein SSH-Nutzer auf SUSE 15/Leap 15 mit Standardkonfiguration von einem normalen Nutzer in einen Root-Nutzer verwandeln. Eine Schwachstelle verschafft den "allow_active"-Status, die andere nutzt diesen Status aus, um vollständige Root-Rechte zu erlangen — und zwar mit vorinstallierten Komponenten. Root-Zugriff erlaubt es, Sicherheitsagenten zu manipulieren, Persistenz herzustellen und sich lateral im Netzwerk zu bewegen. Ein ungepatchter Server kann somit ein Risiko für eine gesamte Infrastruktur darstellen. Sowohl PAM als auch libblockdev/udisks sollten daher auf allen Systemen umgehend aktualisiert werden.
Die technischen Details zu den Schwachstellen finden sich auf dieser Seite.



MVP: 2013 – 2016




Danke für den Hinweis. Mein Mint hat gestern entsprechend folgendes aktualisiert:
libblockdev-crypto3
libblockdev-fs3
libblockdev-loop3
libblockdev-mdraid3
libblockdev-nvme3
libblockdev-part3
libblockdev-swap3
libblockdev-utils3
libblockdev3
libpam-modules-bin
libpam-runtime
libpam0g
libudisks2-0
udisks2
Schönen Feiertag :)
Für SLES 15 SP7 kamen heute entsprechende Pakete (u.a. Kernel und PAM).
pam konfiguriert man sowieso immer selbst und CVE-2025-6019 ist gepatcht.
No Panic!
Die großen Linux-Distributionen reagierten bereits seit Mittwoch. Ubuntu listet zu UDisks USN-7578-2 und zu libblockdev USN-7577-2. Debian liefert zu libblockdev Announce DSA-5943-1.
Das Patching ist primär ein "Hardening": Laut Changelog der Patches mounted Debian mit udisks2 per linuxfilesystemhelpers jetzt private mounts mit "nodev,nosuid". Der Patch von libblockdev (CVE-2025-6019) erschwert durch "dont allow suid and dev set on fs resize" Veränderungen.
Ein ambitionierter Admin war bei Umzusetzung härtender Maßnahmen schon vorher nicht gehindert ;-) – bis zum Mount mit noexec bei "tmp"-Mounts. Zu sonstiger Mitigation oder Auswirkungen von PAM speziell unter Ubuntu/Debian sah ich gerade noch nichts.
In den Repo's zB von Debian existiert Patch und Abhilfe seit gestern Nachmittag.
Bisher hier keine Probleme mit den Patches. Und ja, @TOM, auch Debian Testing ist schon versorgt, frei nach "Sisters | More", "And I need all the Patch I can get" ;-)
Danke für die Hinweise – laut BLEEPINGCOMPUTER ist liblockdev jetzt bei Version 3.3.0-2.1(testing) und udisks2 bei Version 2.10.1-12(testing)!
Ich nutze fast immer die Primärquellen, Repos und Security Announces. Ist oft schneller und präziser als die Blogs. Blogs lese ich eher danach. Vielleicht hilft jemandem die ausgebuffte Klick-Kette. Für Debian Testing zB:
libblockdev zu Security yep, 3.3.0-2.1, dann Packages, dann Link -> Changelog.
udisks2 zu Security yep. 2.10.1-12, dann Packages, dann Link -> Changelog
Dazu ein genereller Überblick der Packages im Debian Security Thread oder wer nicht einschlafen mag den Debian Security Tracker. Nun, für Einsteiger reicht auch ein regelmässiger Blick in die Security Threads…
Auf Raspi OS also Debian gabs heute Updates. Ist halt nicht Microsoft. Und das System funktioniert nach den Updates auch noch.
Super, danke für den Hinweis, werde meinen Server und meinen Raspi gleich schnell updaten :-)
Wenn du das erst nach Tipp vom Born tust, läuft bei dir was falsch.
Und da ist er wieder…
Luis Suárez lässt grüßen