Linux kernel incorrect computation of branch displacements in BPF JIT compiler(openwall.com)
openwall.com
Linux kernel incorrect computation of branch displacements in BPF JIT compiler
https://www.openwall.com/lists/oss-security/2021/04/08/1
19 comments
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.
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
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
# 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
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
> 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.
...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?
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.
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.
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
Did you report this vulnerability just for free?
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.