Interp-flow Hijacking: Launching Non-control Data Attack via Hijacking eBPF Interpretation Flow

Abstract

eBPF (extended Berkeley Packet Filter) is regarded as a secure alternative to kernel modules for enhancing kernel functionalities. As an emerging kernel subsystem, eBPF should not be exploited by kernel vulnerabilities to bypass established protection. Unfortunately, the exploitability of eBPF has not been fully studied so far.

This paper investigates the exploitability of eBPF. Our study uncovers a previously unidentified security risk: eBPF bytecode lacks injection and hijack prevention, thus eBPF interpretation flow can be hijacked to execute malicious bytecode. To understand the risk, we propose Interp-flow Hijacking, a novel attack that hijacks the eBPF interpretation flow to circumvent kernel code and Control Flow Integrity (CFI) protections, thereby enabling arbitrary code execution within the kernel. To realize the attack, we propose a novel technique named Tailcall Trampoline for hijacking the interpretation flow without violating CFI.

To evaluate the exploitability, we formulate CVE requirements and give techniques to pivot different types of CVEs. The evaluation of 16 real CVEs from different kernel subsystems shows that Interp-flow Hijacking can enhance all their capabilities in bypassing kernel protection. Finally, we design and implement a protection mechanism to safeguard against Interp-flow Hijacking. We are communicating with the Linux community to address the identified issues.

This work is partially supported by the National Key R&D Program of China (No. 2022YFE0113200) and the Leading Innovative and Entrepreneur Team Introduction Program of Zhejiang (Grant No. TD2019001).

Appendices

A Analysis Results

We identify 39 exploitable interp-flow data (in Linux 6.1.33), as detailed in Table 4. Some interp-flow data’s size can be determined by the user. Read-only interp-flow data are not listed since they cannot be corrupted by memory bugs.

We further analyze the exploitability of all interp-flow data manually and find that most interp-flow data are related to eBPF hooking. These data cannot be exploited without violating CFI, as discussed in Sect. 4.2. Among other data, bpf_array is the perfect target for interp-flow hijacking, as presented in §4.3.

Table 4. Identified interp-flow data.

Fig. 8.

Arbitrary kernel code execution primitive.

B Arbitrary Kernel Code Execution

We construct arbitrary kernel code execution based on the key observation that the eBPF interpreter handles JMP_CALL (e.g., calling eBPF helper functions) by doing a PC-relative jumping. The interpreter first extracts the offset from eBPF bytecode instruction insn and adds it to __bpf_call_base to get the target address. Next, the interpreter jumps to the target address with at most five parameters prepared in BPF_R1-R5. The possible target addresses can be any eBPF helper functions and other eBPF programs that are too versatile to enforce the CFI checks.

Therefore, we propose to exploit the JMP_CALL to realize arbitrary kernel code execution. The bytecode of the primitive is shown in Fig. 8. Lines 1-4 set up the parameters, and Line 6 triggers the JMP_CALL call, which jumps to ___bpf_call_base+FUNC_OFFSET. Note that the user totally controls the FUNC_OFFSET. Moreover, it is the offset value rather than the runtime address. One can get it from static kernel compilation, thus bypassing kernel ASLR. Besides, FUNC_OFFSET is 32-bit, supporting ±2 GB relative addressing, which is much larger than the kernel text size (less than 100 MB), so arbitrary kernel code execution is achieved.