4 ms·

But that means the root user or someone with root effective privs or CAP_* to load programs into a kernel interpreter or kernel JIT. If you've given someone per

But that means the root user or someone with root effective privs or CAP_* to load programs into a kernel interpreter or kernel JIT. If you've given someone permission to do this from a user process you've probably opened up to more mundane issues. I suspect this is why AMD says the issue is near zero, if you've given away the keys to the kernel you're already in trouble. AMD's ASID blocks the issues for VM guests (and root users on VM guests).

Pyxl101 9y ago
Do you need root or comparable privileges to take advantage of BPF? I did not think that was the case. My understanding was that BPF code executes within the kernel. BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?
- language 9y ago
  iirc I think that the BPF JIT is disabled by default? Your kernel might be compiled with `CONFIG_BPF_JIT`, but I think the sysctl knob (`bpf_jit_enable`) is set to 0 by default. Also there's a sysctl for unprivileged BPF called `unprivileged_bpf_disabled`. On my system it seems to default to 0. https://elixir.free-electrons.com/linux/v4.15-rc6/source/kernel/bpf/syscall.c#L1690 https://elixir.free-electrons.com/linux/v4.15-rc6/source/ker...
comex 9y ago
For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required. For variant 2, Project Zero used the eBPF interpreter as a gadget, a fake branch destination, without having to actually create an eBPF program or use the normal userland-facing eBPF APIs at all. And they only chose it as the least "annoying" option (see quote below). edit: I'm not sure how ASID support would mitigate either of those variants, though there may be something I'm not thinking of. (It would help with variant 3, but that's the variant AMD wasn't vulnerable to in the first place.) quote: > At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.
- caf 9y ago
  To make it a bit clearer how this works: the Variant 2 exploit poisons the branch target buffer to cause the processor's speculative execution in kernel space to jump to an entirely attacker-controlled destination when it hits a branch that matches the information the attacker has placed into the BTB. The actual retired instructions don't go this way of course - the processor detects the misprediction and goes back to execute the real code path - but the speculatively executed path still leaves evidence behind in the caches.
  - tankenmate 9y ago
    But somehow you have to get that kernel address in the first place in order to alias it in the BTB. How do you get that without root?
    - aidenn0 9y ago
      You boot up your own copy of Ubuntu LTS-whatever and read the address of it as root. KASLR is not enabled everywhere, and where it is, there are other attacks to defeat it, which are mentioned in the paper.
    - caf 9y ago
      They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor. See the section "Reading host memory from a KVM guest / Locating the host kernel". It's terribly clever.
      - tankenmate 9y ago
        But if you use AMD ASID it blocks this as memory mappings for VM guests are in a completely separate address space. What I was wondering was for local OS user mode to local OS root / kernel mode access; i.e. user to kernel privilege escalation.

Pyxl101 9y ago

Do you need root or comparable privileges to take advantage of BPF? I did not think that was the case. My understanding was that BPF code executes within the kernel. BPF is employed by the `bpf()` syscall for socket packet filtering, as well as by `seccomp` itself for its syscall filtering. Is this threat vector not available to untrusted processes?

language 9y ago
iirc I think that the BPF JIT is disabled by default? Your kernel might be compiled with `CONFIG_BPF_JIT`, but I think the sysctl knob (`bpf_jit_enable`) is set to 0 by default. Also there's a sysctl for unprivileged BPF called `unprivileged_bpf_disabled`. On my system it seems to default to 0. https://elixir.free-electrons.com/linux/v4.15-rc6/source/kernel/bpf/syscall.c#L1690 https://elixir.free-electrons.com/linux/v4.15-rc6/source/ker...

comex 9y ago

For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required. For variant 2, Project Zero used the eBPF interpreter as a gadget, a fake branch destination, without having to actually create an eBPF program or use the normal userland-facing eBPF APIs at all. And they only chose it as the least "annoying" option (see quote below). edit: I'm not sure how ASID support would mitigate either of those variants, though there may be something I'm not thinking of. (It would help with variant 3, but that's the variant AMD wasn't vulnerable to in the first place.) quote: > At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets.

caf 9y ago
To make it a bit clearer how this works: the Variant 2 exploit poisons the branch target buffer to cause the processor's speculative execution in kernel space to jump to an entirely attacker-controlled destination when it hits a branch that matches the information the attacker has placed into the BTB. The actual retired instructions don't go this way of course - the processor detects the misprediction and goes back to execute the real code path - but the speculatively executed path still leaves evidence behind in the caches.
- tankenmate 9y ago
  But somehow you have to get that kernel address in the first place in order to alias it in the BTB. How do you get that without root?
  - aidenn0 9y ago
    You boot up your own copy of Ubuntu LTS-whatever and read the address of it as root. KASLR is not enabled everywhere, and where it is, there are other attacks to defeat it, which are mentioned in the paper.
  - caf 9y ago
    They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor. See the section "Reading host memory from a KVM guest / Locating the host kernel". It's terribly clever.
    - tankenmate 9y ago
      But if you use AMD ASID it blocks this as memory mappings for VM guests are in a completely separate address space. What I was wondering was for local OS user mode to local OS root / kernel mode access; i.e. user to kernel privilege escalation.