Linux kernel exploits: PwnKit, Dirty Pipe and OverlayFS

A kernel exploit is the last bullet, not the first: it can hang the machine and it is almost never the path the creator intended. But a handful of vulnerabilities are so reliable and so widespread that they are always worth checking, especially on older machines. This guide is about when to try them and which ones.

First: is this the way?

If the machine is from 2020 or later and you have not checked sudo -l, SUID, capabilities, cron and credentials, it is not time yet (see sudo, SUID and capabilities and cron, PATH and groups). Signs that it is:

• The kernel or the OS is very old for the machine's release date.
• There is nothing else after a full enumeration.
• The box hints at it (an email about "patching the kernel" on TwoMillion).

Getting the exact versions

uname -a                       # kernel version
cat /etc/os-release            # distribution and release
sudo --version | head -1       # sudo version
pkexec --version               # polkit (PwnKit)
dpkg -l | grep -E 'linux-image|polkit|sudo'   # packages and their exact patch level

Careful: an Ubuntu with kernel 5.15.0-56 may be patched even if the number "sounds" vulnerable. Distributions backport fixes without changing the base version; compare against the distro's security notice (USN on Ubuntu, DSA on Debian).

Tools that cross-check it for you:

./linux-exploit-suggester.sh            # lists candidate CVEs with their likelihood
./linpeas.sh -s                         # the "Linux Exploit Suggester" section

The ones that work most often

PwnKit and Baron Samedit are not kernel bugs strictly speaking, but you look for them at the same time and they are the first to try: they work without compiling anything exotic and almost never break the box. Baron Samedit is the privesc on RouterSpace; Dirty COW, an alternative path on Valentine.

Compiling without the headache

The exploit has to be built for the same architecture and a compatible glibc. In order of preference:

1. If the target has gcc, compile there: gcc exploit.c -o exp && ./exp.
2. Otherwise compile on your machine statically: gcc -static exploit.c -o exp -lpthread. It works even if the target's glibc is older.
3. For 32-bit: gcc -m32 -static ... (you need gcc-multilib).
4. Some exploits (PwnKit, several OverlayFS ones) have Python or shell versions that need no compiling.

If the binary complains about GLIBC_2.34 not found, you did not build it statically or your glibc is newer: use option 2 or compile inside a container of the same distro release (docker run -it ubuntu:18.04).

Using them carefully

• Read the code first. Many old Exploit-DB exploits modify /etc/passwd or leave the system unstable; back it up (cp /etc/passwd /tmp/passwd.bak) so you can restore it.
• Race-condition exploits (Dirty COW) can take a while or hang the box: try the variants that write a file before the ones that patch memory.
• If the exploit needs it, run from /tmp or /dev/shm and check they are not mounted noexec (mount | grep shm).

If none of this pans out, go back to the Linux privesc cheat sheet: there is almost always something you have not looked at.