🧨 SUDO, YOU HAD ONE JOB!

Hi, now any user can get root — and Microsoft told you this would happen

“Don’t run as root!” — they shouted.
“Use sudo, it’s secure!” — they said.
Well guess what?
Even a user not in sudoers can now gain full root access. All thanks to sudo‘s cozy little bug involving chroot, nsswitch.conf, and your complacency.

🧬 CVE-2025-32463: root access through a homemade nsswitch.conf

This is real. This works on default configs.
No extra tools. No brute force.
Even a basic user with shell access can exploit it via:

bash
sudo -R <controlled-directory>

Here’s what happens:

  1. sudo performs chroot into that directory

  2. Before dropping privileges, it reads /etc/nsswitch.conf — from inside the chroot

  3. The attacker controls that file

  4. It tells NSS to load a malicious .so file

  5. That shared library gets executed as root

  6. Welcome to root shell city

🔥 Works on:

  • Ubuntu 24.04

  • Fedora 41

  • Arch, Debian, Gentoo, SUSE, RHEL

  • WSL 2

  • Azure Linux VMs

  • GitHub Actions self-hosted runners

🔬 Deep Dive: What’s Actually Broken?

sudo is a setuid root binary.
When using sudo -R, it chroots into a specified directory before dropping root.

Then it:

  • Loads /etc/nsswitch.conf in chroot

  • NSS tries to resolve passwd: source

  • Malicious .so is loaded from lib/ inside chroot

  • Code is executed with root privileges

bash
mkdir ~/pwnroot/{etc,lib}
echo 'passwd: files myevil' > ~/pwnroot/etc/nsswitch.conf
gcc -shared -fPIC payload.c -o ~/pwnroot/lib/libnss_myevil.so.2
sudo -R ~/pwnroot id

That’s it.
You’re root.
Even if you’re not listed in sudoers.

🧠 Why Microsoft Doesn’t Rely on Local sudo

This is exactly why Microsoft’s access control revolves around:

  • Microsoft Entra ID

  • Just-In-Time elevation

  • Defender for Endpoint (MDE)

  • Intune Compliance baselines

  • Azure Policy + Guest Configuration

They don’t trust sudo.
They trust managed privilege boundaries.

⚠️ Bonus Bug: CVE-2025-32462

Thought restricting sudo by host would help?

bash
Host_Alias DMZ = myhost1

Think again.
Due to a logic bug, users can bypass host-based sudoers rules like this:

bash
sudo -h attacker-host some-command

The -h flag, meant for sudo -l, is incorrectly applied to command execution.
Result: host rules in sudoers are skipped.

âś… Mitigation Plan

1. Patch sudo to 1.9.17p1

👉 Official Release

Check your systems:

bash
sudo --version

Verify patching status across:

  • Azure Linux VMs

  • WSL 2

  • CI/CD runners

  • DevBoxes and on-prem

2. Add Detection via Microsoft Defender for Endpoint

Track:

  • sudo -R usage

  • Unusual .so loads from user-owned paths

  • Shared library loading before privilege drop

Use custom hunting queries to track abnormal NSS behavior.

3. Enforce Intune Compliance

Deploy scripts to:

  • Check for unpatched sudo versions

  • Disable use of sudo -R

  • Enforce updated packages and restrict LD_LIBRARY_PATH

4. Azure Policy or Guest Configuration

  • Audit for sudo versions < 1.9.17p1

  • Block chroot misconfigurations

  • Enforce minimal privilege

5. Move to Just-In-Time Access via Entra

  • Don’t use sudo as your privilege model

  • Use Entra ID with PIM and Conditional Access

  • Elevate roles temporarily, with full audit

🧨 Summary: What You Thought vs. What’s Real

Assumption Reality
sudo is secure sudo can grant root to anyone
chroot isolates chroot enables exploitation
NSS is boring config NSS is an execution vector
Root is locked down Root is exposed via misused defaults

🗣️ Final Thoughts

sudo is old.
Microsoft’s identity and privilege model left that era behind long ago.
Conditional Access, Defender, Intune, Policy as Code — these aren’t just nice-to-haves. They’re the reason your system isn’t compromised already.

This CVE proves it: local tools are not enough.
Least privilege and secure elevation must be centrally managed.

So if you’re still handing out sudo like it’s Halloween candy — don’t be surprised when someone unwraps root access.