Hacker News new | past | comments | ask | show | jobs | submit login
Linux kernel incorrect computation of branch displacements in BPF JIT compiler (openwall.com)
111 points by panic 25 days ago | hide | past | favorite | 19 comments

I always believe allowing any forms of JIT (in userspace programs) by default creates unnecessary security risks - only a handful of programs use it. The sysadmin should have a choice to enforce strict W^X on all programs and to whitelist JIT-enabled applications only when needed.

The kernel space BPF JIT in particular, is an huge attack vector and has been repeatably exploited (or facilitated other exploits) in the past. If you don't need BPF JIT, I recommend disabling it. Sure, tcpdump or nftable may be slower, but often it doesn't matter, unless it's a cutting edge production system which actually relies on BPF JIT. It can either be removed completely when building the kernel, setting "net.core.bpf_jit_enable" in sysctl to disable it globally, or setting "kernel.unprivileged_bpf_disabled" to disable it for unprivileged programs.

I’ve gone with the KSPP suggestion:

# Turn off unprivileged eBPF access.

kernel.unprivileged_bpf_disabled = 1

# Turn on BPF JIT hardening, if the JIT is enabled.

net.core.bpf_jit_harden = 2


Not all JITs are WX. TurboFan in V8 is W^X.

PaX's implementation of W^X (MPROTECT) is stricter - you can disallow any attempt to introduce new executable code, including writing to memory first and giving it executable status later.

> Linux kernel incorrect computation of branch displacements in BPF JIT compiler...

...can be abused to execute arbitrary code in Kernel mode

to complete what has been cut off in the title.

Ironically tough, running user code in the kernel was kind of the original idea.

Am I understanding correctly that this affects any kernel where custom BPF rules can be applied? Can this be done from within a linux container?

Things like containers, chroots, and UML only provide isolation to things that play nicely. Often all three are pretty easy to escape if you want to.

Depending on how the container runtime is configured, yes.

Pretty great that the fix is accompanied with a unit test to make sure it never regresses going forward!

That's not a fix, just a kinda assertion that nobody falls into that PoC. The real fix would in the compiler to correctly adjust its sizes and addr[] amongst its optimization paths. The optimizer end condition also seems fishy to me, solely relying on the size. Optimized passes can still be better within the same size.

It feels like a BPF JIT would be a good candidate for "verifiable" development. Can anyone knowledgeable opine on whether it would be feasible or desirable to prove the correctness of this component? (I suppose this will necessitate writing in a suitable language/DSL too.)

A quick search for "verified bpf compiler" found this: https://github.com/uw-unsat/jitterbug

A "direct" correctness proof of a BPF compiler written in C would be hard because C is hard to reason about. If you pulled it off, you could do this verification before compiling the kernel.

It would certainly be easier to implement an "indirect" approach using translation validation, i.e., taking the code generated by the compiler and checking that it is semantically equivalent to the input BPF code. The problem with this is that this would need to be done at run time, i.e., you would add a lot of verification time when the user is already waiting for the BPF program to run.

Overall: Yes, this is a good candidate, and people are on it.

The patches are from 2001???

They are not. See: https://git-scm.com/docs/git-format-patch#_discussion

To quote the relevant bit:

"The patch produced by git format-patch is in UNIX mailbox format, with a fixed "magic" time stamp to indicate that the file is output from format-patch rather than a real mailbox".

The date "Mon Sep 17 00:00:00 2001" is that magic date.

What a hack

Why would an unprivileged user be permitted to provide BPF programs?

To support socket and seccomp filters.

Did you report this vulnerability just for free?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact