CVE-2025-32463 macht’s möglich
In der Linux-Welt ist es gängige Praxis, mit nicht-privilegierten Nutzerkonten zu arbeiten. Aus gutem Grund: So wird die Angriffsfläche für Schadsoftware und Fehlkonfigurationen deutlich reduziert. Für bestimmte Administrationsaufgaben ist jedoch ein temporärer Zugriff mit erweiterten Rechten notwendig. Genau hier kommt das weit verbreitete Tool sudo ins Spiel, das mit großer Macht ausgestattet ist und somit auch ein potenziell riskanter Angriffsvektor sein kann.
In diesem Beitrag geht es um die kritische Sicherheitslücke CVE-2025-32463, die genau dieses Werkzeug betrifft. Es wird erklärt, worin die Schwachstelle besteht, wie sie technisch ausgenutzt werden kann und warum sie als besonders gefährlich eingestuft wird. Außerdem wird gezeigt, wie sich mit dem Enginsight SIEM überprüfen lässt, ob das eigene System betroffen ist oder ob bereits ein Exploitversuch stattgefunden hat.
Was ist CVE-2025-32463?
Im Juni 2025 wurde eine schwerwiegende Sicherheitslücke in einem der grundlegendsten Werkzeuge fast aller Linux-Distributionen entdeckt: dem sudo-Befehl. Die Lücke trägt die Kennung CVE-2025-32463 und betrifft alle Versionen von sudo zwischen 1.9.14 und 1.9.17, also auch solche, die in weit verbreiteten Distributionen wie Ubuntu, Red Hat oder SUSE standardmäßig enthalten sind. Die Schwachstelle hat einen CVSS-Wert von 9.3, was sie als kritisch einstuft.
Die Lücke entsteht durch einen Fehler im Umgang mit der --chroot-Option von sudo. Normalerweise ermöglicht sudo einem Benutzer mit eingeschränkten Rechten, ausgewählte Befehle mit administrativen Rechten auszuführen. Seit Version 1.9.14 gibt es jedoch die Möglichkeit, über --chroot (bzw. deren Kurzform sudo -R) ein alternatives Root-Verzeichnis (chroot) anzugeben. Genau hier liegt das Problem: Während der Überprüfung der sudoers-Richtlinien wird das chroot bereits aktiviert und das erlaubt es einem Angreifer, eine manipulierte Umgebung bereitzustellen.
In dieser gefälschten Umgebung befindet sich eine speziell präparierte Konfigurationsdatei namens /etc/nsswitch.conf. Diese Datei gehört zur Standardinfrastruktur von Linux-Systemen und bestimmt, wie die Namensauflösung im System funktioniert, wie beispielsweise Benutzer-, Gruppen- oder Hostnamen nachgeschlagen werden (z. B. via files, ldap, dns, etc.).
Beim Einlesen der sudoers-Datei muss sudo genau solche Informationen auflösen, etwa um zu prüfen, ob ein Benutzer bestimmte Befehle ausführen darf. Dafür nutzt sudo intern die C-Standardbibliothek glibc, die wiederum die nsswitch.conf konsultiert. Ist diese manipuliert, kann dort z. B. ein Eintrag wie passwd: evilmodule stehen, der ein benutzerdefiniertes Modul angibt.
Die Folge: glibc versucht, die zugehörige Shared Library für dieses Modul zu laden und da sich sudo zu diesem Zeitpunkt bereits im manipulierten chroot-Dateisystem befindet, wird die Library aus genau dieser Umgebung geladen. Sie stammt also vom Angreifer, wird mit Root-Rechten geladen und direkt ausgeführt.
Damit erhält der Angreifer vollständige Kontrolle über das System, ohne Passwortabfrage und ohne bekannte sudo-Bypasses. Die Kombination aus frühzeitig aktiviertem chroot, manipulierten Namensauflösungsmechanismen und automatischem Laden von Shared Libraries macht diese Schwachstelle besonders kritisch.
Warum ist die Schwachstelle so gefährlich?
Obwohl CVE-2025-32463 „nur“ lokal ausgenutzt werden kann, also ein Angreifer bereits Zugriff auf das Zielsystem haben muss, handelt es sich dennoch um eine besonders kritische Schwachstelle. Denn, sobald ein Benutzer über ein kompromittiertes Konto, einen einfachen Shell-Zugang zum System hat, kann er diese Lücke ausnutzen, um sich sofort Root-Rechte zu verschaffen, ganz ohne Passwortabfrage und ohne komplexe Exploit-Ketten.
Besonders heikel wird die Situation in Multi-User-Umgebungen, in Containern oder bei gemeinsam genutzten Test- und Entwicklungsservern: Hier reicht es, wenn ein einzelner Benutzer oder Dienst kompromittiert wird, etwa durch eine Phishing-Attacke, eine fehlerhafte Webanwendung oder eine falsch gesetzte Berechtigung. Der Angreifer könnte sich dann in Sekunden vom normalen Benutzer zum Root-Nutzer eskalieren und damit jede Sicherheitsgrenze aufheben.
Die CVE wird bereits aktiv ausgenutzt
Über GitHub stellt Sicherheitsforscher Rich Mirch einen funktionierenden Proof-of-Concept zur Verfügung: https://github.com/kh4sh3i/CVE-2025-32463/blob/main/exploit.sh
Das Skript demonstriert, wie sich die Schwachstelle in sudo ausnutzen lässt.
Im Zentrum des Exploits steht die Funktion woot(). Sie befindet sich in einer manipulierten Shared Library und wird automatisch ausgeführt, sobald sudo die Bibliothek lädt. Möglich wird das durch ein sogenanntes Constructor-Attribut im Quellcode: Dieses sorgt dafür, dass woot() noch vor dem eigentlichen Programmstart aktiv wird, also unmittelbar beim Laden der Bibliothek. So übernimmt der Angreifer mit wenigen Zeilen Code die Kontrolle über das System.
Was tut woot() genau?
1. Root-Rechte erzwingen:
Die Funktion ruft setreuid(0, 0) und setregid(0, 0) auf. Diese beiden Systemaufrufe setzen die effektive Benutzer- und Gruppen-ID auf 0 – also auf die Root-ID. Wenn der Prozess von sudo gestartet wird, läuft er ohnehin mit erhöhten Rechten, und durch diese Befehle übernimmt die Funktion diese Root-Rechte vollständig für den eigenen Kontext.
2. Wechsel ins Wurzelverzeichnis:
Mit chdir("/") wechselt die Funktion ins Root-Verzeichnis, also an den Anfang der Dateisystemstruktur. Das ist eher kosmetisch, hilft aber sicherzustellen, dass der Benutzer nach dem Exploit in einem sauberen, bekannten Ort landet und nicht in einem verwirrenden Pfad aus dem chroot.
3. Start einer Root-Shell:
Schließlich startet die Funktion mit execl("/bin/bash", "/bin/bash", NULL) eine neue Bash-Shell. Da die Rechte zuvor auf Root gesetzt wurden, ist auch diese Shell eine Root-Shell, der Benutzer hat damit vollständige Kontrolle über das System.
Bin ich betroffen? – Antworten dank Enginsight SIEM
Der Exploit wurde erfolgreich auf einem Ubuntu-24.04-System getestet. Im Enginsight SIEM lassen sich dabei verdächtige Aktivitäten nachvollziehen, insbesondere durch die Auswertung von Prozessstarts. Konkret handelt es sich um von Sysmon für Linux erzeugte ProcessCreate-Events, die detaillierte Informationen zur gestarteten Kommandozeile liefern. Damit diese Events erfasst werden können, ist es allerdings notwendig, Sysmon aktiv zu betreiben. Eine Anleitung zur Aktivierung von Sysmon findet sich hier: https://docs.enginsight.com/docs/bedienung/plattform/siem/kollektoren#sysmon-integration-unter-linux-optional
Im konkreten Fall fällt auf, dass sudo -R verwendet wird, um in ein Unterverzeichnis namens woot zu chrooten. Gleichzeitig soll dort ein Befehl namens woot ausgeführt werden. Diese Kombination ist auffällig und lässt sich über den SIEM Datalake in Enginsight gut nachvollziehen (siehe nachfolgenden Screenshot).
Um solche Versuche systematisch zu erkennen, empfiehlt es sich, eine dauerhafte Überwachung aller sudo -R-Aufrufe zu etablieren. Dafür kann im Enginsight SIEM ein eigener Stream zur Erfassung dieser spezifischen Befehle sowie ein Workflow zur Alarmierung eingerichtet werden. Da der -R-Parameter in der Praxis nur selten genutzt wird, ist bereits das Auftreten ein wertvoller Indikator für mögliche Missbrauchsversuche.
Enginsight-Partner lesen weitere Details in der Community. – Noch kein Partner? Dann nutze jetzt die Chance zum Partnerwerden oder teste Enginsight 14 Tage gratis.
Fazit
CVE-2025-32463 zeigt eindrucksvoll, wie bereits kleine Designfehler in sicherheitskritischen Tools wie sudo zu vollständigem Root-Zugriff führen können. Besonders tückisch ist, dass der Angriff ohne Passwortabfrage erfolgt und sich rein über eine manipulierte Umgebung samt Shared Library umsetzen lässt. Mit dem Enginsight SIEM lassen sich solche Exploits zuverlässig erkennen und detailliert nachvollziehen, zum Beispiel durch die Überwachung von Prozessstarts und auffälliger Nutzung der --chroot-Option in Kombination mit ungewöhnlichen Shell-Kommandos.
Autorin: Elisa Kasper, Cyber Security Analyst
