
# cve-2025-32463 - Local Privilege Escalation to Root via Sudo chroot in Linux
sudo chroot <dir name> <command>
Execute the command in the selected dir name.
This issue was introduced in sudo v1.9.14, which upgraded the matching handling code when the chroot feature is used.

This new change modifies the root directory id before matching execution of the chroot command. The specific functions are defined in plugins/sudoers/pivot.c. This file (now deleted) defines the pivot_root() and unpivot_root() functions for handling chroot matching logic. Calling these two functions triggers a name service switch (NSS) operation, causing the system to load the /etc/nsswitch.conf configuration file from an untrusted environment (because chroot has already changed to the current root directory id). This configuration file contains directives that instruct the system on how to retrieve information about users, groups, and hosts. It can list multiple sources, which are searched in order until a match is found.
Since /etc/nsswitch.conf contains many line entries, information searches are performed based on the order of the line entries. The key point of the vulnerability is: when performing source lookups in the nsswitch.conf file, the source name is used as part of the shared object path, for example: the ldap source translates to libnss_ldap.so. When the NSS function uses the ldap source, it loads that library.
For an attacker, calling pivot_root() and unpivot_root() triggers NSS operations. Thus, the attacker can construct a chroot root directory under a controlled path, containing an /etc/nsswitch.conf file and malicious library files. The name service can be pointed to a custom NSS module, in which a malicious shared library can be forged.
When the attacker runs sudo -R <fake_root_dir> <command> attempting to execute a command in chroot mode, sudo calls the system's NSS to resolve user/group information without fully verifying permissions, reading the forged /etc/nsswitch.conf which points to a malicious NSS module. At this point, the sudo process has already switched to the fake root directory and is still running with root privileges, so it will load and execute the attacker's malicious shared library code with root privileges.
git clone https://github.com/Spongebob-369/cve-2025-32463.git
cd cve-2025-32463
chmod +x run.sh
./run.sh
# after entering the contain Ubuntu
./sudo-chroot.sh
id