[English]Der sudo-Befehl in Linux erlaubt wegen einer als kritisch eingestuften Schwachstelle CVE-2025-32463 eine lokale Privilegien-Eskalation. Hintergrund ist eine unsaubere Behandlung von /etc/nsswitch.conf, so dass man root-Rechte bekommt.
Anzeige
Das Thema ist mir einmal durch einen Kommentar von Norddeutsch im Diskussionsbereich des Blogs, sowie durch einen Tweet untergekommen. Ich ziehe den Kommentar mal hier in den Beitrag, da ich den Diskussionsbereich zyklisch bereinige.
Linuxuser erwartet eiliges Updaten vom Paket sudo. Priority high, Remote möglich. Dies für diverse Distributionen und Zweige.
Durch einen Bug existiert fehlende Restriktion bei Nutzung von "–host, -h". Diese Option ist per Design für "Remote Code Execution" gedacht. Es ermöglicht hier durch Ausnutzung auf einem Remote Host Privilege Escalation und somit unberechtigte Ausführung.
Ebenso existiert ein Fehler im Umfeld von change root" mit Parameter "–chroot, -R". Dies erlaubt beliebige Code Execution und unterläuft dabei korrekte Limitierungen in der Datei sudoers. Die Datei sudoers bildet wesentliche "Policies" unter Linux ab, sie regelt z.B. die Rechte für Systembenutzer und die Erlaubnis sudo auszuführen.PoC, Abuse oder weitere Infos las ich noch nicht. Mitre hat beim Posting für CVE-2025-32462 und CVE-2025-32463 noch keine Detailinfos und listed "reserved".
Siehe dazu auch Manual Pages "man sudo", "man sudoers" oder Links sudo, sudoers.
Ubuntu nennt bei CVE-2025-32462 25.04 plucky, 24.10 oracular, sowie die gesamte LTS-Reihe: 24.04 noble, 22.04 jammy, 20.04 focal, 18.04 bionic, 16.04 xenial, 14.04 trusty als kritisch, Bei CVE-2025-32463 "nur" 25.04 plucky, 24.10 oracular und 24.04 LTS noble.
Der Security Tracker bei Debian kündigt für Bookworm Version 1.9.13p3-1+deb12u2 und für Bullseye Version 1.9.5p2-3+deb11u2 an. Diese sind derzeit noch nicht auf allen Security-Mirrors.
Eigentlich, …eigentlich gehört SSH produktiv m.E. auch nicht direkt ans Netz.
Inzwischen findet sich zu den verlinkten CVEs schon einige Details. In nachfolgendem Tweet werden mehr Details genannt.
Betroffen sind die sudo-Versionen 1.9.14 bis 1.9.17, und der Tweet verweist auf diese OpenWall-Beschreibung, nach der der Bug in sudo 1.9.17p1 behoben sein soll. Sicherheitsforscher von stratascale haben die Schwachstelle gefunden und zum 30. Juni 2025 in diesem Blog-Beitrag dokumentiert. Golem hat in diesem Artikel eine deutschsprachige Beschreibung des Sachverhalts veröffentlicht.
Anzeige
Anzeige
Danke für den Tipp. Unter Mint kam das gerade rein:
sudo/noble-security 1.9.15p5-3ubuntu5.24.04.1 amd64 [upgradable from: 1.9.15p5-3ubuntu5]
sudo/noble,now 1.9.15p5-3ubuntu5 amd64 [installed,upgradable to: 1.9.15p5-3ubuntu5.24.04.1]
Für die gängigen Distros stehen Updates bereit.
Vorbildlich im Gegensatz zu gewissen anderen Systemen.
Debian 11 (Bullseye) benutzt sudo 1.9.5, ist also außerhalb der verwundbaren sudo-Versionen 1.9.14 bis 1.9.17.
Debian 12 (Bookworm) benutzt sudo 1.9.13, ist also außerhalb der verwundbaren sudo-Versionen 1.9.14 bis 1.9.17.
Deswegen stand auf der Debian-Sudo-Seite bei CVE-2025-32462 und CVE-2025-32463 bei Bullseye und Bookworm auch sofort beidesmal "fixed".
Es musste gar nichts gemacht werden, da das normale Debian nicht betroffen ist.
Bei Debian 12 ist der Benutzer gar nicht in der sudoers-Datei, der sudo-Befehl funktioniert also gar nicht, ohne das man ihn konfiguriert.
Die Sicherheitslücke greift nur, wenn in der sudoers-Datei Anmeldedaten für einen anderen (Remote-) Computer drinstehen.
Wenn in der lokalen sudoers-Datei nur lokale Kontodaten drin stehen, dann kann ein Remote-Angreifer nichts machen.
Bei RedHat stand als Workaround auch drin, dass man nur lokale Anmeldedaten in die sudoers-Datei eintragen soll und remote-Anmeldedaten löschen soll.
Ein externer Angreifer kann keinen chroot-Befehl ausführen, wenn er kein lokales Konto hat.
Für Debian-stable und old-stable besteht also gar kein Problem, denn das war bereits out-of-the-box sicher konfiguriert.
Debian-trixie (testing) und Debian-sid (unstable) sind für den produktiven Einsatz nicht gedacht.
> Deswegen stand auf der Debian-Sudo-Seite bei CVE-2025-32462 und CVE-2025-32463 bei Bullseye und Bookworm auch sofort beidesmal "fixed".
Es musste gar nichts gemacht werden, …<
Das ist didaktisch falsch, insofern der Umstand, dass "gar nichts werden musste", in der leider zweideutigen Debian-Terminologie an der massgeblichen Stelle durch "Fixed Version (not affected)" [1] und nicht einfach nur 'fixed' angezeigt wird.
[1] Bsp.: https://security-tracker.debian.org/tracker/CVE-2025-32463
Auf deinem Link für CVE-2025-32463 steht bei Bullseye und Bookworm in der Spalte "fixed Version":
"Not affected"
In dem Link aus dem Artikel steht bei Bullseye und Bookworm:
"fixed"
security-tracker. debian. org/tracker/source-package/sudo
Allerdings gibt es da eine Abweichung zwischen dem Blog-Artikel hier und dem Debian-Artikel.
"Betroffen sind die sudo-Versionen 1.9.14 bis 1.9.17"
gegenüber "Sudo before 1.9.17p1".
Debian hat vorsorglich den Fix auch in nicht betroffene Versionen integriert.
Gegen die andere Sicherheitslücke CVE-2025-32462 braucht aber auch Debian Bullseye und Bookworm einen Fix, denn da steht "vulnerable".
security-tracker. debian. org/tracker/CVE-2025-32462
Die beiden Vorbedingungen zur Ausnutzung deser Sicherheitslücke sind aber recht unwahrscheinlich:
"To exploit this vulnerability on a system, an attacker must have access to an account on that system. Additionally, the system's sudoers file must contain rules that define that user's privileges on a different system."
access. redhat. com/security/cve/cve-2025-32462
"the requirement that an attacker must have access to a valid account on a system"
access. redhat. com/security/cve/cve-2025-32463
Wenn der Angreifer kein Komto auf dem System hat (also Benutzername, Passwort), dann kann er es auch nicht angreifen.
Das potentielle Opfer muss also nur vermeiden, dem Angreifer ein Konto auf dem Opferrechner anzulegen bzw darf dem Angreifer keine Passwörter herausgeben und schon ist es sicher.
Es sei denn der Angreifer ist ein interner Mitarbeiter, der sowieso ein lokales Konto hat. Das dürfte man aber leicht im Log feststellen können und dann schmeißt man diesen internen Saboteur raus und zeigt ihn an, denn dessen Klarname ist ja dann bekannt.
Für die andere Sicherheitslücke 32462 müssen zusätzlich zu diesem lokalen Konto für den Angreifer auch noch in der sudoers-Datei die Zugangsdaten für ein Konto auf einem weiteren anderen System eingetragen worden sein.
Das ist nun wirklich reichlich unwahrscheinlich.
Da müssten die Admins und die Benutzer fahrlässig sein.
Einfach keine Remote-Kontodaten in der lokalen sudoers speichern und man ist sicher.
Das schreibt auch Red Hat als Schutz gegen 32462:
"Mitigation
For environments using sudoers files: Remove rules defined in sudoers files that are for any system other than the local system."
—-
GB: Hab den Kommentar umgehängt.
> Das potentielle Opfer muss also nur vermeiden, dem Angreifer ein Konto auf dem Opferrechner anzulegen … und dann schmeißt man diesen internen Saboteur raus und zeigt ihn an, denn dessen Klarname ist ja dann bekannt. <
Ein im 'Wenn und Aber' verfangenes Sicherheitsdenken ist nicht gut. Wenn neue, abgesicherte Kompilate bereitstehen, sollte man diese grundsätzlich und prioritär auch einspielen.
Debian hat gerade folgendes released:
sudo (1.9.13p3-1+deb12u2) bookworm-security; urgency=high
* Non-maintainer upload by the Security Team.
* Local Privilege Escalation via host option (CVE-2025-32462)
— Salvatore Bonaccorso Tue, 24 Jun 2025 09:29:50 +0200
Zitat aus dem Heise-Newsticker-Artikel zu der sudo-Lücke:
"Der Entdecker, Rich Mirch von "Stratascale Cyber Research Unit", konnte nicht alle Versionen testen. Er ist jedoch sicher, die Lücke sei in älteren Versionen vor sudo 1.8.32 nicht enthalten, da der schadhafte Code erst in dieser Version auftauchte. In den von ihm getesteten stabilen Versionen 1.9.14 bis 1.9.17 findet sich der Bug."
heise. de/news/chwoot-Kritische-Linux-Luecke-macht-Nutzer-auf-den-meisten-Systemen-zu-Root-10466885.html
—
Demnach befindet sich die Sicherheitslücke nicht erst seit v1.9.14 in sudo, sondern das ist lediglich die *niedrigste gestestete* Version.
v1.9.,13 und v1.9.5 könnte also durchaus auch betroffen sein, aber das hat der Entdecker nicht explizit untersucht.
Dann wäre die Aussage von Debian doch die bessere, denn sie haben nur eine obere Versiongrenze und keine untere Versionsgrenze angegeben.
In so einem Fall wäre eine KI nützlich, die mal eben die betroffenen Versionen konkret auflistet, nachdem sie sämtliche Versionen automatisch untersucht hat.
Ein Beleg dafür, dass diese chroot-Sicherheitzslücke erst mit v1.9.14 eingebaut worden ist und nicht schon vorher vorhanden war:
Zitat:
"Improved command matching when a chroot is specified in sudoers. The sudoers plugin will now change the root directory id needed before erforming command matching. Previously, the root directory was simply prepended to the path that was being processed."
github. com/sudo-project/sudo/blob/SUDO_1_9_14/NEWS
Debian 11 und 12 sind also nicht betroffen, weil sie ältere sudo-Versionen benutzen.
Es werden ja hoffentlich noch nicht alle Administratoren sämtlicher Hostinganbieter im Urlaub verschwunden sein, zumal man heutzutage bei jedem kleinen Centhosting schon SSH Zugang auf die Kiste kriegt, wo zahlreiche weitere Nutzer Ihre Accounts liegen haben, ansonsten halt Rootser er mit geblocktem SSH Port oder Managed, da liegt die Verantwortung beim Betreiber.
Ich finde schön, dass sich die Kollegen aus der Linux-Fraktion hier so sachlich austauschen können, und wie ihr seht, werdet ihr dabei eigentlich auch in Ruhe gelassen. Es wird euch wegen dieser Sicherheitslücke, die ja nun glücklicherweise geschlossen wurde und noch glücklichererweiserer offensichtlich noch nicht so lange existierte, kein Vorwurf gemacht, das falsche Betriebssystem zu nutzen, auch keine unflätigen Zwischeneinwürfe. Im Gegensatz zu Artikeln zu Windows-Problemen wird euch daher keiner hier auffordern, deswegen auf Windows zu wechseln. Ihr habt euer Betriebssystem nach Anforderung, Kenntnissen und Vorliebe ausgewählt und das respektiert die andere Seite. Ich bitte euch daher, euch auch bei Artikeln zu Windows-Themen genauso respektvoll zu verhalten! Danke!
Ich lasse deinen Kommentar jetzt ausnahmsweise mal so stehen – aber mein Hinweis: im Sinne von "sehr weit vom Artikelthema weg" werden solche Kommentare künftig gelöscht. Und ich werde hier auch jegliche Antworten auf den Vorkommentar löschen – es führt zu nichts.
Künftige Kommentarlöschungen durch mich als Blog-Betreiber
In openSUSE Tumbleweed ist sudo ab dem Snapshot vom 02.Juli 2025 gefixt.
"sudo (1.9.16p2 -> 1.9.17p1)"
download. opensuse. org/tumbleweed/iso/Changes.MicroOS.20250702.txt
Nach Update und Neustart zeigt der Befehl
zypper info sudo
die Version an:
1.9.17p1
Dazu zeigt er auch die Quelle für sudo an:
www. sudo. ws
Geht man auf diese Seite, dann sieht man, dass die Version vom 30.6.2025 stammt.
" This version fixes a security issue (CVE-2025-32462)
[…]
"This version fixes a security issue (CVE-2025-32462)"
In der unteren Zeile ist aber ein Typo, denn der dahinter liegende Link führt zu CVE-2025-32463 (3 statt 2), also der anderen Lücke.
Beide Lücken sind gefixt.