Skip to content

Elevating Privileges: SUID

In the last example we saw how administrators could give users Sudo rights for individual files. However this has an overhead of requiring every user (or group of users) in the system to have an entry in the sudoers file.

Linux addresses this problem of everyone needing elevated privileges by using the SUID and SGID permissions flag. This is a special setting for the standard file permissions that allows a program to be run with the privileges of either the Owner (SUID) or Group (SGID). Essentially this allows a user to run a program as a different user, and gives admins control over who (or what) can access files.

This gives us some advantages over the sudo based approach. allowing programs that ALL users may need to run but also require elevated permissions can be dealt with on a per-file bases

Note

The SUID setting is the basis of the exploit in level 18 of the Linux trainer. You can try it again with the password b5cc9840b9bc42c93a0aee2bf87e3f0b

The Password Example

Lets use the passwd from before command as an example. This is owned by the root user, meaning it can access the privileged files required, but has the SUID bit set. This means that users can run the (well tested, and checked for security flaws) program as root allowing them to change their own password.

We can see if a file has SUID privileges using the ls -l command, if there is an s in the execute bit.

For example the sudo command shows the following privileges.

$ls -l /usr/bin/sudo 
-rwsr-xr-x 1 root root 140600 Jan 13 12:40 /usr/bin/sudo

Given that SUID files allow us to run commands as a privileged user, they can often be the weak point that allows us to gain further control of a system. As we saw in article on systems enumeration, its often worthwhile looking at all SUID / SGID binaries to check for flaws.

SUID files

We could look for all SUID files on the system with the find command[^linpeans]

$ find / -perm -4000 2>/dev/null
/usr/bin/pkexec
/usr/bin/fusermount
/usr/bin/mount
/usr/bin/ksu
/usr/bin/nvidia-modprobe
/usr/bin/chsh
/usr/bin/mount.cifs
/usr/bin/gpasswd
/usr/bin/chfn
/usr/bin/vmware-authd
/usr/bin/unix_chkpwd
/usr/bin/screen-4.8.0
/usr/bin/umount
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/su
/usr/bin/chage
/usr/bin/expiry
/usr/bin/newgrp
/usr/bin/sg
/usr/lib/ssh/ssh-keysign

You can see that there are a lot of standard SUID file with SUID permissions. Most of these are for the same reason as the passwd command discussed above. Things like mounting and unmounting drives are essential for regular users to do (for example dealing with USB drives), but also require access to the underlying file system. Usually, we can rely on these system level functions to have strong security1.

However, its also good practice to audit the SUID files on a system, any unusual ones should be investigated to see if there are potential vulnerabilities. Good candidates are SUID files outside of the usual /*/bin folders.

Task

Just for fun, there is a vulnerability in the list above. Can you spot which one it is...

Summary

Using SUID is another common way to elevate privileges on a system. It can be incredibly useful for allowing programs that need low level access to be run by standard users. However, if misconfigured it can lean to During a pen-test it is worth examining the SUID files to see if there are any with known vulnerabilities.

  1. But you keep up to date with CVE's right.... ↩

  2. We will cover linpeas and friends next week. ↩

Back to top