31–40 of 46 posts
Earlier quoted context omitted.
Easier to get started maybe, but there's something to be said for the 'ease' of having to worry a lot less about crashing the kernel you're working on.
I've crashed multiple kernels with eBPF programs. I don't buy this argument at all.
Earlier quoted context omitted.
I call bullshit! Ebpf programs cannot crash the kernel since they cannot be run if they contain bugs in the first place.
That assumes that the virtual machine has no bugs
>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
The BPF capability should really only be given to root. I don't think it really gives any new attack surface. All I could see is it giving black-hats an easier interface to "kernel-level-fuckery".
They should probably put it behind its own capability like CAP_LOAD_EBPF.
Forcing signed ebpf will also help though.
>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
Yes, especially with Spectre. I looked into using eBPF with seccomp (which currently only supports BPF) and the consensus seemed to be that they're not going to add any more eBPF to the kernel and have basically given up on making it secure. I wouldn't be surprised if it becomes entirely root-only by default soon, if it isn't already.
One cool project that uses eBPF is Cilium. It allows restricting network traffic to / from containers in Kubernetes. Many of the problems it solves, in my opinion, are better solved via user-space solutions, e.g. service-to-service traffic is better controlled via signing / encryption, but overall Cilium is a pretty cool piece of technology.
>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
I think they already don't. eBPF has become a favorite jumping point for exploit chains that can very quickly escalate some read/write gadget into full execution.
One cool project that uses eBPF is Cilium. It allows restricting network traffic to / from containers in Kubernetes. Many of the problems it solves, in my opinion, are better solved via user-space solutions, e.g. service-to-service traffic is better controlled via signing / encryption, but overall Cilium is a pretty cool piece of technology.
It seems nice to have both layers. mTLS is great, but you're still exposing your TLS stack to the attacker. Dropping the packet altogether seems nicer.
>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
>eBPF programs can’t access arbitrary kernel memory. Instead the kernel provides functions to get at some restricted subset of things. I must finally becoming a security pessimist when I read those sentences and the first thing I think is: these statements will not age well.
Are you saying this is factually wrong? I assume eBPF is designed to only access certain points explicitly coded in the kernel but the exploits can access any part of kernel. Is this what you are hinting at? Could you please clarify the statement.
First: eBPF code is JIT'd in the kernel; at runtime, it is simply native code running at CPL0 alongside the rest of the kernel. Running eBPF code working with pointers is... working with raw pointers. There's no interpretation layer to bounds check or otherwise provide safety.
But eBPF code is meant to be safe: you can get a handle to some kernel structure that's passed to you from trusted code, but you can't bounce from it to a random offset in kernel memory. The way eBPF does this is by verifying the CFG of your eBPF program before it's translated to amd64 or arm. eBPF programs are generally just C programs (the simplest and best way to write an eBPF program is just to write a C program and compile it with the right LLVM flags), and verifying C programs is a hard problem; eBPF gets around this by only accepting a subset of all possible programs (those where memory accesses are simple enough to prove safe, that don't jump anywhere outside of known narrow range of program text, and that don't have unbounded loops).
The tricky thing here is that the eBPF verifier is pretty complicated and lives only in the kernel. People have found bugs in it. If you find a good verifier bug, you can launder an untrusted pointer into your eBPF program (in the end, these bugs end up looking sort of like the browser Javascript RCEs that finagle a bad pointer out of some part of the browser API).
The biggest mitigating factor for these bugs is that Linux systems generally don't expose eBPF to any user other than root, so the upside to these kinds of bugs is limited (it gives you root->kernel, which is not nothing, but not the top of most people's priority list).
The other big issue is that eBPF is a huge source of in-kernel flexibility about runnable code. Modern exploit mitigations are in large part about making sure that instructions running at CPL0 are all known, so that if you manage to corrupt allocator metadata or write an arbitrary 8 byte value at an arbitrary 8 byte offset you can't easily turn that into remote code execution. But, of course, eBPF is an in-kernel JIT; it's there to run essentially random code inside the kernel. eBPF code is normally constrained, but if you have a kernel memory corruption bug, you can aim it at the eBPF subsystem and violate the kernel's assumptions.
Earlier quoted context omitted.
I think they already don't. eBPF has become a favorite jumping point for exploit chains that can very quickly escalate some read/write gadget into full execution.
I would love to read an in depth breakdown of an exploit using eBPF as part of its execution chain. Do you happen to have an example/link?
Scroll down to "The ultimate ROP"