Breaking the eBPF Sandbox: From Unprivileged User to Ring-0

TLDR: The eBPF subsystem has become a massive, high-privilege attack surface that most security teams treat as a "black box" of safety. This research demonstrates how to systematically identify and exploit verifier and JIT compiler vulnerabilities to achieve full kernel compromise. By using the Leviathan framework, researchers can now automate the discovery of complex vulnerability chains across multiple CPU architectures.

The industry has spent years treating eBPF as a secure, sandboxed environment for observability and networking. We trust the verifier to stop malicious code before it ever touches the kernel. We assume that if a program passes the verifier, it is safe. That assumption is fundamentally broken. When you look at the eBPF subsystem not as a security feature, but as a complex, in-kernel virtual machine running with ring-0 privileges, the threat model shifts entirely.

The Verifier is the Primary Attack Vector

The eBPF verifier is a 15,000-line C masterpiece that is also a massive, complex attack surface. Its job is to prove that an arbitrary user-supplied program is safe to execute in the kernel. If you can find a way to trick the verifier into miscalculating bounds or misidentifying types, you have effectively bypassed the entire security architecture.

My research into CVE-2020-8835, CVE-2021-3496, and CVE-2022-23222 revealed a clear pattern: verifier complexity is directly proportional to exploitability. The verifier attempts to track register states across complex code paths. When it fails to account for specific edge cases—like integer overflows or inconsistent type tracking—it opens the door to memory corruption.

Consider a simple bounds calculation error. If the verifier incorrectly tracks the min_value and max_value of a register, an attacker can craft a program that passes verification but performs an out-of-bounds read or write once it hits the JIT compiler.

// Simplified verifier logic flaw
if (reg->min_value + offset < reg->max_value) {
    // The verifier assumes this path is safe
    allow_access = true;
}

By manipulating the offset and the register state, you can force the verifier to allow access to memory regions it should have blocked. Once you have that primitive, you are no longer just running a packet filter; you are running an exploit in the heart of the kernel.

Systematic Exploitation with Leviathan

Manual analysis of these vulnerabilities is slow and requires deep expertise in both the verifier and the specific JIT compiler implementation for the target architecture. To solve this, I developed Leviathan. Instead of relying on random mutation, which is largely ineffective against a smart verifier, Leviathan generates programs that specifically target known vulnerability classes.

The framework focuses on three core pillars:

1. Verifier State Tracking: Analyzing how the verifier handles complex state transitions.
2. JIT Compiler Fuzzing: Targeting architecture-specific bugs in how eBPF bytecode is translated to native code for x86-64, ARM64, RISC-V, and PowerPC.
3. Helper Function Abuse: Exploiting the 200+ helper functions that provide the interface between eBPF and the kernel.

When you run Leviathan, it doesn't just crash the kernel; it builds a chain. It starts by finding an information leak to defeat KASLR, then uses a memory corruption primitive to gain arbitrary read/write, and finally escalates privileges by modifying the task structure of the current process.

Real-World Impact for Pentesters

If you are performing a red team engagement or a kernel-level security audit, eBPF is the first place you should look. Most modern Linux distributions ship with eBPF enabled by default. If a container or a user has the CAP_BPF capability or access to bpf() syscalls, they have a direct line to the kernel.

During an engagement, don't just look for misconfigurations. Look for the ability to load eBPF programs. If you can load a program, you can use a framework like Leviathan to probe the verifier for weaknesses. The impact is total system compromise. You aren't just breaking out of a container; you are taking control of the host kernel.

Hardening the Subsystem

Defending against these attacks requires more than just patching individual CVEs. We need to move toward a model of "defense in depth" for the kernel itself.

First, implement strict input validation for all eBPF helper functions. If a helper function doesn't need to access a specific memory region, it shouldn't be able to. Second, move toward fine-grained privilege separation for eBPF programs. Not every observability tool needs the same level of access to the kernel's internal structures. Finally, audit your infrastructure. If you aren't logging eBPF program loads and the associated bytecode, you are flying blind. You need to know exactly what code is being injected into your kernel, and you need to be able to perform forensic analysis when things go wrong.

The "hivemind" of the kernel is only as secure as the code we allow to run inside it. Stop treating eBPF as a safe sandbox and start treating it as the high-stakes, high-privilege environment it actually is. The next time you see an eBPF-based security tool, ask yourself: what happens if that tool is the one that gets compromised?