Date: Wed, 11 Sep 2024 12:21:09 +0100 From: David Chisnall <theraven@freebsd.org> To: Vadim Goncharov <vadimnuclight@gmail.com> Cc: Philip Paeps <philip@trouble.is>, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, tech-net@netbsd.org Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <E46A2E65-C529-4A74-984B-27E75CB77936@freebsd.org> In-Reply-To: <20240911120518.1ba191b5@nuclight.lan> References: <20240911120518.1ba191b5@nuclight.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 Sep 2024, at 10:06, Vadim Goncharov <vadimnuclight@gmail.com> wrote: >=20 > But then a possibility to give this to non-root is. And many things are > considered vulnerabilitites even if they are only available to root - > for example, when root can be tricked into running malicious code etc. > (unconscious) actions without direct intention. When the root user intentionality changes some thin from a secure default to= an insecure setting, it is not a security vulnerability in the system that s= hipped the safe defaults.=20 > Equivalency of classic BPF to writable /dev/mem is too loud and > controversial statement. Demonstrate how it can be done on stock > FreeBSD 13 with /dev/bpf available to attacker (e.g. `sudo tcpdump` > allowed). Two things to unpick here. First: Demanding a proof of concept before you accept that something is a vulnerabi= lity is how you build insecure systems. Ask the Matrix team how well that at= titude has worked for them in the last few weeks. You build secure systems b= y defining a threat model and then evaluating primitives against that threat= model, not by throwing together a bunch of primitives and saying =E2=80=98w= ell, *I* can=E2=80=99t assemble them into an exploit and so no one can=E2=80= =99. Second, there are documented attacks on eBPF that give the equivalent of *re= ad* access to /dev/mem. This is why BPF is restricted to root. We have a thr= eat model. The threat model says that we do not need to ensure that BPF cann= ot leak kernel data indirectly because only the user who has the ability to l= eak kernel data directly can use it and this user has a simpler way of achie= ving the same result. If you allow non-root users to run code (native or aga= inst any virtual machine) then you are changing the threat model. You *must*= prevent users from leaking kernel data that they could not leak via existin= g mechanisms. The two most common attacks using eBPF are generally in the following two ca= tegories: - Use eBPF to mount a speculative execution attack on the kernel. Please re= ad up on what these can do. No one should be building a thing that runs code= in the kernel without understanding speculative, cache, and timing side cha= nnels. - Use eBPF to build a set of gadgets that you can then use to go from one m= emory-safety bug in the kernel to arbitrary-code execution. This is the threat landscape in which something in the same space as eBPF mu= st exist. A proposed design should *start* with an explanation of how it mit= igates both of these categories of attack. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E46A2E65-C529-4A74-984B-27E75CB77936>