eBPF Offensive Capabilities – Get Ready for Next-Gen Malware (2023) | Hacker News Reader

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

sysdig.com

89 pointspassword432113 comments

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.

> 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.

Depends on the scene. This is why my portfolio companies as well as my previous employer when I was a PM and SWE began moving engineering (and even PM) hiring to Israel, CEE, and India.

I've noticed a severe degradation in OS, Systems, and Networking knowledge in the US market over the past 15 years.

Everyone went gungho into "fullstack" or "backend" and significantly deskilled.

> Netlink is pretty awesome

It really is. Most security products will use a mix of Netlink and eBPF to gain observability and enforcement capabilities on Linux workloads.

> 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)

Big reason most companies I know of would prevent third party software from being granted CAP_NET_ADMIN

I don’t think I’d call netlink awesome. Ever had to program with it?

Yes I have actually. I have used it from userspace for all sorts of things, including crazy things like reading out conntrack state to build network flow visualisation etc. I have also implemented my own kernel modules that used netlink for userspace communication.

I think awesome in kernel terms is always relative. It's awesome compared to ioctl or custom character devices (or the very dirty option of custom syscalls). I suspect io_uring would be a much much nicer alternative but it's also much more modern and not something I have worked with yet.

Am I reading this wrong, or is it a variant of "If you have kernel access you can mess with userland"?

Do you mean having malware code already running in kernel space, or having system permissions to install new kernels?

For the latter case, there are now mechanisms that aim to prevent root from modifying the kernel or otherwise getting ring 0 access, see eg https://www.man7.org/linux/man-pages/man7/kernel_lockdown.7....

But even in a non locked down mode, there are practical advantages for the adversary in using officially supported interfaces vs their own kernel module or leveraging some i/o path to access kernel memory.

No, you're reading it right.

I guess one point of the article is that eBPF-injected programs are another place where malware can hide. But then again, it's easy to list all currently loaded eBPF programs (well, unless there's a way to somehow hide/disconnect them, but keep them running).

IIUC TFA, you could hook the syscall that shows all eBPF programs

not a ebpf expert, just been on my radar lately because i’m going through a sysdig poc.

To me It feels more like a reverse proxy for intercepting traffic going between user land and kernel space.

As we move to k8s and classic EDR isn’t feasible i 100% understand the need. It still feels like a dumb thing humanity has done and will blow up in our face after having the kernel / user space security boundary beat into our heads for so long.

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?

It also prevents backwards edges in the control flow graph; no loops (unless entirely unrolled), no recursion

The verifier is mostly targeted at not letting a program run forever.

Reply on news.ycombinator.com