Was ist CVE-2025-32463?<\/h3>\n\n\n\n
Im Juni 2025 wurde eine schwerwiegende Sicherheitslücke in einem der grundlegendsten Werkzeuge fast aller Linux-Distributionen entdeckt: dem Die Lücke entsteht durch einen Fehler im Umgang mit der In dieser gefälschten Umgebung befindet sich eine speziell präparierte Konfigurationsdatei namens 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 Die Folge: Damit erhält der Angreifer vollständige Kontrolle über das System, ohne Passwortabfrage und ohne bekannte 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Ü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<\/a><\/p>\n\n\n\n Das Skript demonstriert, wie sich die Schwachstelle in sudo ausnutzen lässt.<\/p>\n\n\n\n Im Zentrum des Exploits steht die Funktion 1. Root-Rechte erzwingen:<\/strong><\/p>\n\n\n\n Die Funktion ruft 2. Wechsel ins Wurzelverzeichnis:<\/strong><\/p>\n\n\n\n Mit 3. Start einer Root-Shell:<\/strong><\/p>\n\n\n\n Schließlich startet die Funktion mit Der Exploit wurde erfolgreich auf einem Ubuntu-24.04-System getestet. Im Enginsight SIEM<\/a> 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 Im konkreten Fall fällt auf, dass Um solche Versuche systematisch zu erkennen, empfiehlt es sich, eine dauerhafte Überwachung aller Enginsight-Partner lesen weitere Details in der Community<\/a>. – Noch kein Partner? Dann nutze jetzt die Chance zum Partnerwerden<\/a> oder teste Enginsight 14 Tage gratis<\/a>.<\/p>\n\n\n\n <\/p>\n\n\n\n Fazit<\/strong><\/p>\n\n\n\n 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 Autorin: Elisa Kasper, Cyber Security Analyst<\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":30,"featured_media":35505,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_eb_attr":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-35418","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-inside-enginsight"],"_links":{"self":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/35418","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/users\/30"}],"replies":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/comments?post=35418"}],"version-history":[{"count":0,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/posts\/35418\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media\/35505"}],"wp:attachment":[{"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/media?parent=35418"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/categories?post=35418"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/enginsight.com\/de\/wp-json\/wp\/v2\/tags?post=35418"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}sudo<\/code>-Befehl. Die Lücke trägt die Kennung CVE-2025-32463 und betrifft alle Versionen von sudo<\/code> zwischen 1.9.14 und 1.9.17<\/strong>, 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<\/strong>, was sie als kritisch einstuft.<\/p>\n\n\n\n--chroot<\/code>-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 <\/code>(bzw. deren Kurzform sudo -R<\/code>) 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.<\/p>\n\n\n\n\/etc\/nsswitch.conf<\/code>. 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.).<\/p>\n\n\n\nglibc<\/code>, die wiederum die nsswitch.conf konsultiert. Ist diese manipuliert, kann dort z. B. ein Eintrag wie passwd: evilmodule stehen, der ein benutzerdefiniertes Modul angibt.<\/p>\n\n\n\nglibc <\/code>versucht, die zugehörige Shared Library für dieses Modul zu laden und da sich sudo zu diesem Zeitpunkt bereits im manipulierten chroot<\/code>-Dateisystem befindet, wird die Library aus genau dieser Umgebung geladen. Sie stammt also vom Angreifer, wird mit Root-Rechten geladen und direkt ausgeführt.<\/p>\n\n\n\nsudo<\/code>-Bypasses. Die Kombination aus frühzeitig aktiviertem chroot, manipulierten Namensauflösungsmechanismen und automatischem Laden von Shared Libraries macht diese Schwachstelle besonders kritisch.<\/p>\n\n\n\nWarum ist die Schwachstelle so gefährlich? <\/strong>
<\/h3>\n\n\n\nDie CVE wird bereits aktiv ausgenutzt<\/h2>\n\n\n\n
woot()<\/code>. 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()<\/code> 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.<\/p>\n\n\n\nWas tut woot() genau?<\/h3>\n\n\n\n
setreuid(0, 0)<\/code> und setregid(0, 0)<\/code> 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.<\/p>\n\n\n\nchdir("\/")<\/code> 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. <\/p>\n\n\n\nexecl("\/bin\/bash", "\/bin\/bash", NULL)<\/code> 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.<\/p>\n\n\n\nBin ich betroffen? – Antworten dank Enginsight SIEM<\/h2>\n\n\n\n
ProcessCreate-Events<\/code>, 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<\/a><\/p>\n\n\n\nsudo -R<\/code> verwendet wird, um in ein Unterverzeichnis namens woot <\/code>zu chrooten. Gleichzeitig soll dort ein Befehl namens woot<\/code> ausgeführt werden. Diese Kombination ist auffällig und lässt sich über den SIEM Datalake in Enginsight gut nachvollziehen (siehe nachfolgenden Screenshot).<\/p>\n\n\n\n![\"\"\/](\"https:\/\/tribe-s3-production.imgix.net\/yDLrJo3g1dwK4nkz10UGE?auto=compress,format\")
sudo -R<\/code>-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-<\/code>Parameter in der Praxis nur selten genutzt wird, ist bereits das Auftreten ein wertvoller Indikator für mögliche Missbrauchsversuche.<\/p>\n\n\n\n--chroot<\/code>-Option in Kombination mit ungewöhnlichen Shell-Kommandos.<\/p>\n\n\n\n