July 24th, 2024

eBPF Offensive Capabilities – Get Ready for Next-Gen Malware (2023)

eBPF technology in the Linux kernel allows low-level program execution, posing security risks as attackers can exploit its features. Safeguards exist, but ongoing vigilance is essential to mitigate potential abuses.

Read original articleLink Icon
eBPF Offensive Capabilities – Get Ready for Next-Gen Malware (2023)

eBPF (Extended Berkeley Packet Filter) is a powerful technology integrated into the Linux kernel that allows programs to run at a low level without needing kernel modules. While it has legitimate uses in security monitoring and performance analysis, it also poses risks as it can be exploited for malicious purposes. eBPF programs can be attached to various hooks in the kernel, such as kprobes, uprobes, tracepoints, and traffic control hooks, enabling attackers to monitor and manipulate kernel and user-space functions.

The article discusses the offensive capabilities of eBPF, highlighting how attackers can abuse its features. For instance, they can directly access maps to alter the logic of eBPF programs, use kprobes to hide processes or files, and manipulate network traffic through traffic control hooks. Uprobes can also be exploited to change the behavior of user-space applications.

To mitigate these risks, the kernel employs a verifier that checks eBPF bytecode for safety before execution, ensuring that potentially harmful operations are prevented. Despite these safeguards, the potential for abuse remains significant, necessitating ongoing vigilance in monitoring and securing systems that utilize eBPF technology. The article emphasizes the importance of understanding both the capabilities and the risks associated with eBPF as it becomes increasingly integrated into cloud-native environments and security frameworks.

Link Icon 6 comments
By @jpgvm - 10 months
There is lots of interesting kernel surface that is rarely locked down. eBPF is a (relative) the new kid on the block but there is also Netlink and the other new kid io_uring. Unfortunately security features for these transports are limited so if you have to say run a daemon that manages network device state that now becomes attack surface for other juicy things you can do with Netlink (because once you have CAP_NET_ADMIN everything is up for grabs). io_uring is similar in this regard with both currently pretty much "trusted" APIs.

Netlink is pretty awesome, you can sort of think of it like ioctl on steroids. As a result it's proliferated around the kernel as much nicer replacement for ioctls or implementing a custom character device or something for userspace/kernel communication.

Knowledge of this isn't widespread however, even security experts I have spoken to that don't have deep kernel development background aren't really aware of how widespread Netlink is in generic non-network related subsystems.

By @red_admiral - 10 months
Am I reading this wrong, or is it a variant of "If you have kernel access you can mess with userland"?
By @miggol - 10 months
The sudoers example to me was the most illustrative.

Though it's still not exactly clear to me what the verifier intends to prevent. I can understand that it limits how far you can look up into the stack and what memory your eBPF program can read. But can we otherwise just run any random code in eBPF? The register value tracking and DAG stuff kind of goes over my head.

In short, could I write a Scheme in eBPF and pass it a program at runtime, through a map?