Sudo Vulnerability: The Privilege Escalation Attack You Need to Know

A new critical vulnerability has been discovered in sudo (or super user do), the essential Linux program that allows users to run commands with elevated privileges. This security flaw enables local attackers to escalate their privileges to root level by exploiting a logic issue in sudo's implementation, potentially giving them complete control over affected systems.

What Is Sudo and Why Is It Important?

Sudo is a fundamental utility in Linux systems that allows users to execute commands with the security privileges of another user, typically the superuser (root). When you run commands like 'sudo apt install' to install packages, you're temporarily elevating that process's privileges to perform actions that require root access.

What makes sudo particularly interesting from a security perspective is how it works. Sudo is a binary located at /usr/bin/sudo that's marked with a special permission called 'setUID'. This permission tells the kernel to run the program with the privileges of the user who owns the file (root) rather than the user who executed it. This mechanism is what allows sudo to elevate privileges temporarily.

The Newly Discovered Vulnerability

The recently identified vulnerability (CVE) allows attackers to trick sudo into loading an arbitrary shared library using a user-specified root directory via the chroot option. This is not a memory corruption issue but rather a logical flaw in how sudo handles trust boundaries.

The vulnerability allows loading arbitrary shared libraries through a user-specified root directory

The vulnerability stems from the intersection of two specific features within sudo:

The chroot option (-r) which creates a file system jail
Sudo's use of the NSS (Name Service Switch) mechanism

Understanding Chroot and NSS Switch

To understand this vulnerability, we need to grasp two key concepts: chroot and NSS switch.

Chroot (change root) is a mechanism that changes the apparent root directory for a running process and its children. It essentially creates a file system jail where the process cannot access files outside the specified directory. When you execute 'sudo chroot /path/to/jail', the process will see /path/to/jail as its root (/) directory.

Chroot jails require all necessary libraries and dependencies to function properly

NSS (Name Service Switch) is a system facility that manages various databases of system information, such as users, passwords, and groups. The configuration file /etc/nsswitch.conf tells the system where to look for this information. NSS uses shared libraries to implement different sources of this information, such as files, LDAP, or other services.

How the Exploit Works

The vulnerability allows attackers to combine these features in an unexpected way to gain root access. Here's how the exploit works:

The attacker creates a custom directory structure with their own version of /etc/nsswitch.conf
This custom nsswitch.conf file is configured to use a malicious shared library for handling user information
The attacker creates this malicious shared library with code that will execute when loaded
Using sudo's chroot option, the attacker makes sudo use their custom directory as the root
When sudo needs to verify user information, it loads the attacker's malicious library
Since sudo runs with root privileges, the malicious code in the library also executes with root privileges

The -r command option in sudo allows specifying a chroot directory, which is exploited in this attack

Technical Details of the Proof of Concept

The proof of concept exploit created by security researcher Rich Felker demonstrates this vulnerability clearly. It involves creating a malicious shared object (named woot1337.so.2) with a constructor function that runs automatically when the library is loaded.

This constructor sets the effective user ID and group ID of the process to 0 (root), changes the current directory to the real root directory, and then executes arbitrary commands with root privileges.

/* Simplified version of the exploit code */

__attribute__((constructor))
static void init(void) {
    /* Set effective user and group to root (0) */
    seteuid(0);
    setegid(0);
    
    /* Change to the real root directory */
    chdir("/");
    
    /* Execute commands as root */
    system("/bin/bash");
}

The attacker also creates a custom nsswitch.conf file that directs any password-related lookups to use their malicious library:

TEXT

# Custom nsswitch.conf
passwd: woot1337
shadow: files
group:  files
# ... other entries ...

Why This Vulnerability Is Particularly Interesting

What makes this vulnerability especially noteworthy is that it's not a memory corruption issue that could be prevented by using memory-safe programming languages like Rust. It's a logic flaw in how sudo handles trust boundaries between the chroot environment and the system libraries it loads.

This is particularly relevant given the recent discussions about rewriting sudo in Rust (sudo-rs) to improve security. While Rust would prevent memory-related vulnerabilities, it wouldn't have prevented this specific logical vulnerability, as the issue lies in the design rather than in memory management.

Protecting Your Systems

To protect against this vulnerability, system administrators should:

Update sudo to the latest version that patches this vulnerability
Limit which users have sudo access on production systems
Consider implementing the principle of least privilege, giving users only the specific permissions they need
Monitor for unusual sudo usage patterns that might indicate exploitation attempts

Conclusion

This sudo vulnerability highlights that security is multifaceted and goes beyond just preventing memory corruption issues. Even with the adoption of memory-safe languages like Rust, logical vulnerabilities in program design can still pose significant security risks.

The incident serves as a reminder that security must be considered at all levels of software development—from language choice to architecture design to implementation details. As we continue to improve security practices, we must remain vigilant against all types of vulnerabilities, not just those that can be solved by changing programming languages.

Understanding the Latest Sudo Privilege Escalation Vulnerability and Its Impact