{"id":138584,"date":"2025-07-01T17:11:57","date_gmt":"2025-07-01T15:11:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-utilite-sudo-pozvolyayushhie-poluchit-prava-root-v-sisteme"},"modified":"2025-07-01T17:11:57","modified_gmt":"2025-07-01T15:11:57","slug":"uyazvimosti-v-utilite-sudo-pozvolyayushhie-poluchit-prava-root-v-sisteme","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/uyazvimosti-v-utilite-sudo-pozvolyayushhie-poluchit-prava-root-v-sisteme","title":{"rendered":"Schwachstellen im Programm sudo, die es erm\u00f6glichen, Root-Rechte im System zu erlangen.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Im sudo-Paket, das zur Ausf\u00fchrung von Befehlen im Namen anderer Benutzer verwendet wird, wurde eine Schwachstelle (CVE-2025-32463) entdeckt, die es jedem nicht privilegierten Benutzer erm\u00f6glicht, Code mit Root-Rechten auszuf\u00fchren, selbst wenn der Benutzer nicht in der sudoers-Konfiguration erw\u00e4hnt wird. Betroffen sind Distributionen, die die Konfigurationsdatei \/etc\/nsswitch.conf verwenden; die M\u00f6glichkeit, die Schwachstelle auszunutzen, wurde beispielsweise in Ubuntu 24.04 und Fedora 41 demonstriert. <\/p>\n
Die Schwachstelle tritt in der Standardkonfiguration auf und wurde in den sudo-Versionen von 1.9.14 bis 1.9.17 best\u00e4tigt (potenziell sind alle Versionen ab 1.8.33 betroffen). Das Problem wurde im Update sudo 1.9.17p1 behoben. Den Status der neuen Paketversion oder die Vorbereitung eines Patches in den Distributionen kann man auf den folgenden Seiten \u00fcberpr\u00fcfen (wenn die Seite nicht verf\u00fcgbar ist, bedeutet das, dass die Entwickler der Distribution noch nicht mit der Bearbeitung des Problems begonnen haben): Debian, Ubuntu, Fedora, SUSE\/openSUSE, RHEL, Gentoo und Arch (1, 2). <\/p>\n
Das Problem liegt darin, dass beim Verwenden der Option «-R» («—chroot») zum Ausf\u00fchren von Befehlen in einer chroot-Umgebung mit dem ausgew\u00e4hlten Wurzelverzeichnis die Datei \/etc\/nsswitch.conf im Kontext des neuen Wurzelverzeichnisses und nicht des Systemverzeichnisses geladen wurde. Da der Benutzer sein eigenes Verzeichnis als Wurzelverzeichnis f\u00fcr chroot verwenden kann, kann er darin die Konfigurationsdatei nsswitch.conf ablegen. Indem er die von der NSS-Subsystem (Name Service Switch) geladene Datei \/etc\/nsswitch.conf kontrolliert, kann der Benutzer Einstellungen hinzuf\u00fcgen, die die Ausf\u00fchrung zus\u00e4tzlicher Handler ausl\u00f6sen. Solche Handler werden von NSS in Form von Shared Libraries geladen, die ebenfalls im vom Benutzer kontrollierten Verzeichnis platziert werden k\u00f6nnen. Indem er seine Bibliothek einf\u00fcgt, kann der Benutzer erreichen, dass Code mit Root-Rechten aus ihr ausgef\u00fchrt wird, da die Behandlung von NSS vor der Zur\u00fccksetzung der Berechtigungen erfolgt. <\/p>\n
In der Version sudo 1.9.17p1 wurde auch eine weitere Sicherheitsanf\u00e4lligkeit (CVE-2025-32462) behoben, die es erm\u00f6glicht, Befehle mit Root-Rechten auszuf\u00fchren, jedoch nur in sudoers-Konfigurationen, bei denen der Parameter «host» auf einen Wert gesetzt ist, der sich von ALL oder dem Namen des aktuellen Hosts unterscheidet. Die Sicherheitsanf\u00e4lligkeit wird durch einen Fehler verursacht, durch den die Option «-h» («—host») nicht nur in Kombination mit der Option «-l» («—list») zur Anzeige der hostgebundenen Berechtigungen, sondern auch beim Ausf\u00fchren von Befehlen wirkte. Dadurch konnte der Benutzer bei der Ausf\u00fchrung von sudo jeden Host angeben und die Beschr\u00e4nkungen der sudoers-Regeln umgehen, die an den Hostnamen gebunden sind. <\/p>\n
Um einen Angriff durchzuf\u00fchren, muss der Benutzer in den sudoers erw\u00e4hnt werden, z. B. wenn in den Einstellungen «testuser testhost = ALL» angegeben ist, konnte der Benutzer «testuser» «sudo -h testhost» angeben und Befehle mit Root-Rechten auf beliebigen Hosts ausf\u00fchren und nicht nur auf dem Host testhost. Von der Sicherheitsanf\u00e4lligkeit sind Konfigurationen mit Einstellungen wie «testuser ALL = ALL» oder ohne explizite Regeln f\u00fcr bestimmte Benutzer nicht betroffen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"