Linux local privilege escalation

Linux local privilege escalation exploits misconfigurations in file permissions, sudo policies, scheduled tasks, service configurations, and kernel vulnerabilities to move from a standard user to root on a compromised host.

Strategic context

Linux privilege escalation is a local activity. It begins after initial access has provided a shell as a non-root user and internal reconnaissance is complete. The enumeration conducted during internal reconnaissance directly informs which escalation paths are available.

The most reliable Linux escalation techniques exploit misconfigurations rather than software vulnerabilities. Sudo policies that grant unintended access, SUID binaries that allow shell escaping, writable scheduled tasks, and overly permissive file permissions are configuration issues that can be fixed through disciplined system administration. Kernel exploits exist but carry higher risk and should be used sparingly.

For security leaders, Linux local privilege escalation shows the importance of configuration hardening beyond initial deployment. Default sudo policies, inherited file permissions, and legacy scheduled tasks accumulate over time and create escalation paths that are not detected by standard vulnerability scanning.

Execution examples

Sudo misconfigurations

The sudo configuration defines which commands a user can execute with elevated privileges. Misconfigurations frequently allow unintended escalation.

sudo -l

This output reveals which commands the current user can run as root. Many standard utilities, text editors, file viewers, scripting interpreters, can be used to escape to a root shell when executed with sudo. GTFOBins maintains a complete reference of these escape sequences.

Some sudo configurations allow loading shared libraries before execution:

# If env_keep includes LD_PRELOAD
sudo LD_PRELOAD=/tmp/malicious.so allowed_command

The LD_PRELOAD technique works by loading a shared library that spawns a root shell before the intended command executes.

One notable sudo vulnerability is CVE-2019-14287, which bypasses restrictions on root execution when the sudoers file contains (ALL, !root):

sudo -u#-1 /bin/bash

SUID and SGID binaries

Files with the SUID bit set execute with the file owner's privileges rather than the executing user's privileges. When a SUID binary owned by root can be manipulated into executing arbitrary commands, it provides root access.

find / -perm -u=s -type f 2>/dev/null

Common escalation paths include SUID binaries that call other programs without absolute paths (PATH manipulation), binaries that load shared objects from writable locations (shared object injection), and standard utilities with known shell escape sequences.

PATH manipulation works when a SUID binary executes a command by name rather than by full path:

export PATH=/tmp:$PATH
echo '/bin/bash' > /tmp/called_command
chmod +x /tmp/called_command
./suid_binary

Capabilities

Linux capabilities provide fine-grained privilege assignment to binaries. A binary with cap_setuid+ep can change its user ID to root:

getcap -r / 2>/dev/null

If a scripting interpreter like Python has the cap_setuid capability:

python3 -c 'import os; os.setuid(0); os.system("/bin/bash")'

Scheduled task exploitation

Cron jobs that execute writable scripts or reference non-existent files in writable directories provide escalation opportunities.

cat /etc/crontab
ls -la /etc/cron*

If a cron job runs as root and executes a script that the current user can modify or replace, inserting a reverse shell payload into that script provides root access at the next execution interval.

Cron jobs that use wildcards in commands (such as tar *) can also be exploited by creating files whose names are interpreted as command arguments.

NFS root squashing

NFS shares configured with no_root_squash allow remote root users to maintain root privileges on the exported filesystem. If such a share is writable, a SUID binary can be placed on it from the attacker's machine and executed on the target:

# Check exports
cat /etc/exports

# From attacker machine
mount -o rw target:/export /mnt/target

Docker group membership

Membership in the docker group provides effective root access by allowing the user to mount the host filesystem into a container:

docker run -v /:/mnt --rm -it alpine chroot /mnt sh

Kernel exploits

Kernel exploits target vulnerabilities in the operating system kernel itself. They are effective against unpatched systems but carry risk. a failed kernel exploit can crash the system.

uname -a

The kernel version determines which exploits may apply. Notable examples include DirtyCow (CVE-2016-5195) and DirtyPipe (CVE-2022-0847).

The best source for kernel exploits is https://www.exploit-db.com/.

Common mistakes

• Running automated enumeration scripts without understanding the environment

• Focusing on kernel exploits before checking for misconfigurations

• Not checking sudo permissions, which is often the fastest path to root

• Modifying system files without considering the impact on stability

Operator notes

• Check sudo permissions first

• Check SUID binaries and capabilities next

• Kernel exploits should be a last resort due to stability risk

• LinPEAS is useful for thorough enumeration but should supplement manual checks

• GTFOBins is an essential reference for evaluating sudo-allowed commands and SUID binaries