6 ms·

Linux kernel incorrect computation of branch displacements in BPF JIT compiler

111 points by panic 5y ago

VWWHFSfQ 5y ago
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?
- tptacek 5y ago
  Depending on how the container runtime is configured, yes.
- swiley 5y ago
  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.
pdenton 5y ago
The patches are from 2001???
- TheDong 5y ago
  They are not. See: https://git-scm.com/docs/git-format-patch#_discussion 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.
  - londons_explore 5y ago
    What a hack
- saagarjha 5y ago
  https://stackoverflow.com/a/27005870/5230900 https://stackoverflow.com/a/27005870/5230900
EdSchouten 5y ago
Pretty great that the fix is accompanied with a unit test to make sure it never regresses going forward!
- rurban 5y ago
  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.
st_goliath 5y ago
> 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.
bcaa7f3a8bbc 5y ago
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.
- helloooooooo 5y ago
  Not all JITs are WX. TurboFan in V8 is W^X.
  - bcaa7f3a8bbc 5y ago
    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.
- nominated1 5y ago
  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_Project/Recommended_Settings#sysctls https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
jjjeii3 5y ago
Did you report this vulnerability just for free?
Y_Y 5y ago
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.)
- tom_mellior 5y ago
  A quick search for "verified bpf compiler" found this: https://github.com/uw-unsat/jitterbug 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.
jeffbee 5y ago
Why would an unprivileged user be permitted to provide BPF programs?
- tptacek 5y ago
  To support socket and seccomp filters.

111 points by panic 5y ago

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?

tptacek 5y ago
Depending on how the container runtime is configured, yes.
swiley 5y ago
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.

pdenton 5y ago

The patches are from 2001???

TheDong 5y ago
They are not. See: https://git-scm.com/docs/git-format-patch#_discussion 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.
- londons_explore 5y ago
  What a hack
saagarjha 5y ago
https://stackoverflow.com/a/27005870/5230900 https://stackoverflow.com/a/27005870/5230900

EdSchouten 5y ago

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

rurban 5y ago
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.

st_goliath 5y ago

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

bcaa7f3a8bbc 5y ago

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.

helloooooooo 5y ago
Not all JITs are WX. TurboFan in V8 is W^X.
- bcaa7f3a8bbc 5y ago
  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.
nominated1 5y ago
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_Project/Recommended_Settings#sysctls https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

jjjeii3 5y ago

Did you report this vulnerability just for free?

Y_Y 5y ago

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

tom_mellior 5y ago
A quick search for "verified bpf compiler" found this: https://github.com/uw-unsat/jitterbug 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.

jeffbee 5y ago

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

tptacek 5y ago
To support socket and seccomp filters.