Introduction to `su` and Setuid Binaries

The su (substitute user) command is a cornerstone of privilege management in Unix-like operating systems. It allows a user to run commands with the privileges of another user, most commonly the root user. Its critical role in system administration makes it a prime target for attackers seeking privilege escalation. Understanding how su works, its inherent security model, and potential vulnerabilities is crucial for both offensive and defensive security professionals.

At the heart of su‘s functionality is the setuid bit. When this special permission bit is set on an executable file, the program will run with the effective user ID (EUID) of the file’s owner, rather than the EUID of the user executing it. For /bin/su, this bit is set, and the owner is typically root. This means that when a regular user executes su, the binary itself runs with root privileges, allowing it to perform actions like changing the current user ID to root’s ID after successful authentication.

The Setuid Mechanism and Its Security Implications

The setuid bit is a powerful feature, but it introduces a significant security surface. Any vulnerability within a setuid root binary can be leveraged by a local attacker to gain root privileges. Therefore, such binaries are typically coded with extreme caution, often sanitizing environment variables, strictly validating inputs, and carefully managing execution paths.

You can identify setuid binaries on your system using the find command:

find / -perm -4000 2>/dev/null

This command searches the entire filesystem for files with the setuid bit set. For su, you’ll typically see something like this:

ls -l /bin/su
-rwsr-xr-x 1 root root 40304 May  1 2023 /bin/su

The ‘s’ in the user permission field (-rws) indicates the setuid bit is active.

Common Vulnerability Vectors in `su` Implementations

While standard su implementations are heavily scrutinized and generally robust, custom or older versions, or even specific system configurations, can introduce vulnerabilities. Here are common vectors:

• Incorrect Permissions/Ownership: If su or critical files it relies on (like PAM configuration files) have incorrect permissions (e.g., world-writable), an attacker might tamper with them.
• PATH Environment Variable Manipulation: Some setuid binaries might execute external commands without specifying their absolute paths. If an attacker can manipulate the PATH environment variable, they could trick the setuid binary into executing a malicious program instead of the intended one. Modern su typically sanitizes PATH.
• Race Conditions (TOCTOU): Time-Of-Check To Time-Of-Use vulnerabilities can occur when a program checks a file’s state (e.g., permissions) and then performs an action on it, but the file’s state changes between the check and the action. This can be exploited with symbolic links or temporary file creation.
• Environment Variable Attacks (e.g., LD_PRELOAD): Some dynamic linkers honor environment variables like LD_PRELOAD, which can force a program to load an arbitrary shared library before any others. If a setuid binary doesn’t properly sanitize the environment, an attacker could inject malicious code. Again, modern su is designed to prevent this.
• Improper Input Validation: Although less common in su itself, buffer overflows or format string bugs in auxiliary functions could theoretically be exploited.

Reverse Engineering a Suspected Vulnerable `su` Binary

When investigating a potentially vulnerable su binary (perhaps a custom vendor-specific implementation or an older version), reverse engineering is key. The goal is to understand its internal logic, how it handles input, what external commands it executes, and how it manages privileges.

Tools for Reverse Engineering:

1. objdump/readelf: For basic static analysis, examining symbols, sections, and dependencies.
2. Disassemblers (e.g., IDA Pro, Ghidra, radare2): To convert machine code back into assembly, providing a low-level view of the program’s execution flow.
3. Debuggers (e.g., GDB): For dynamic analysis, stepping through the code, inspecting memory, and observing function calls. Note that debugging setuid binaries as a non-root user is often restricted.

Key Areas to Examine:

• Main Function and Argument Parsing: How does su handle command-line arguments (e.g., -c for executing a command)? Look for input validation routines.
• Privilege Management: Identify calls to setuid(), seteuid(), setgid(), setegid(). Understand when and how privileges are dropped or escalated. A common pattern is to drop privileges for certain operations and re-elevate them only when strictly necessary.
• External Command Execution: Look for functions like system(), execve(), execl(), popen(). Pay close attention to the paths used for these commands. Are they absolute (e.g., /bin/bash) or relative (e.g., just bash)? If relative, it’s a potential PATH exploitation vector.
• Environment Variable Handling: See how environment variables are read, sanitized, or cleared. Vulnerable binaries might not clear dangerous variables like LD_PRELOAD.
• File Operations: Examine calls to open(), access(), stat(), especially with temporary files or configuration files. This can reveal race condition opportunities.

Example: Analyzing `execve` Calls

Using a disassembler, you might look for cross-references to functions like execve. A snippet might look like this (pseudo-assembly):

...  mov    rax, QWORD PTR [rbp-0x28]  ; Path to executable
  mov    rsi, QWORD PTR [rbp-0x30]  ; Arguments
  mov    rdx, QWORD PTR [rbp-0x38]  ; Environment
  mov    rax, 0x3b                  ; syscall number for execve
  syscall                         ; Execute the command
...

The key here is examining the value in rax (the path). Is it hardcoded to /bin/sh or derived from a user-controlled variable? What about the environment block (rdx)?

Exploitation Scenario: PATH Environment Variable Attack (Conceptual)

Imagine a hypothetical vulnerable su binary (let’s call it /usr/local/bin/vulnerable_su) that, instead of calling /bin/sh directly, calls sh without an absolute path when executing a command passed via -c. Furthermore, it fails to sanitize the PATH environment variable.

Steps to Exploit:

1. Create a malicious shell script:

   echo '#!/bin/bash' > /tmp/sh
   echo '/bin/bash -p' >> /tmp/sh
   chmod +x /tmp/sh

   This script will execute an interactive root shell (-p preserves privileges if run setuid). Note: On modern Linux, -p might not be necessary if the shell itself is invoked with root privileges, but it’s good practice for clarity.

2. Manipulate the PATH environment variable:

   export PATH="/tmp:$PATH"

   This prepends /tmp to your PATH, ensuring that when vulnerable_su searches for sh, it finds your malicious script first.

3. Execute the vulnerable binary:

   /usr/local/bin/vulnerable_su -c "sh"

   If vulnerable, vulnerable_su, running as root, will search PATH for sh, find /tmp/sh, and execute it, leading to a root shell.

Mitigation and Best Practices

Preventing su binary exploits requires a multi-layered approach:

• Strict Input Validation: All input to setuid binaries must be rigorously validated to prevent injection attacks, buffer overflows, and other forms of manipulation.
• Environment Sanitization: setuid binaries should explicitly clear or control critical environment variables (like PATH, LD_PRELOAD, IFS, etc.) before performing privileged operations.
• Absolute Paths: Always use absolute paths for executing external commands within setuid binaries (e.g., /bin/sh instead of sh).
• Principle of Least Privilege: Drop root privileges as soon as they are no longer needed, and re-elevate them only for specific, necessary operations.
• Secure Coding Practices: Adhere to secure coding standards, perform regular code reviews, and use static/dynamic analysis tools.
• System Hardening: Implement security modules like AppArmor or SELinux to enforce mandatory access control policies, restricting what even a compromised setuid binary can do.
• Keep Systems Updated: Ensure your operating system and all software are regularly updated to patch known vulnerabilities in core utilities like su.

By understanding the inner workings of su and the potential attack vectors, developers can write more secure code, and system administrators can better protect their environments against privilege escalation attempts.