1 |
On Thu, Jan 4, 2018 at 8:17 AM, Rich Freeman <rich0@g.o> wrote: |
2 |
> On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird <corbinbird@×××××××.net> wrote: |
3 |
>> |
4 |
>> According to the Project Zero documentation .... having BPF JIT enabled |
5 |
>> is the key to the exploit. |
6 |
>> |
7 |
>> The way the docs read ... can it be assumed that by having BPF JIT |
8 |
>> disabled on an AMD, that blocks this exploit? |
9 |
>> |
10 |
> |
11 |
> I'm still working through the details, but AMD seems to only be |
12 |
> vulnerable to variant 1 (based on AMD's reports), and for Linux that |
13 |
> requires that BPF JIT be both built into the kernel (compile-time), |
14 |
> and enabled in sysctl (net.core.bpf_jit_enable). From what I can tell |
15 |
> variant 1 requires that the vulnerable code actually be executed in |
16 |
> the kernel security context. I'm sure a fix to BPF will be made to |
17 |
> close that. There might also be some other code that can be tricked |
18 |
> in the kernel but there are no reports of this. |
19 |
> |
20 |
> For variant 2 (not exploitable on AMD), it sounds like the BPF code |
21 |
> need merely be present in kernel virtual memory while running in user |
22 |
> security context. That would mean that it would need to be built at |
23 |
> compile-time, and loaded (if in a module), but it wouldn't have to be |
24 |
> enabled in sysctl. I didn't see any mention of it but I would think |
25 |
> that the PTI fixes might close this hole on Intel, since then when the |
26 |
> CPU is in user security context the BPF code would not be present in |
27 |
> virtual memory. Intel posted a separate compile-time fix to lkml |
28 |
> yesterday as well, with an amusing response from Linus in his usual |
29 |
> style, and an even more amusing subsequent joke about needing to add a |
30 |
> perl interpreter to the kernel. |
31 |
> |
32 |
> Variant 1 does exploit CPU behavior, but I suspect it could be fixed |
33 |
> with a change to gcc to recognize these kinds of indirect memory |
34 |
> references and ensure they're not executed speculatively. That fix |
35 |
> would be applicable to anything that runs untrusted code in a sandbox, |
36 |
> such as browsers. That variant isn't about crossing CPU privilege |
37 |
> boundaries so much as getting code that is legitimately being run to |
38 |
> leak state through the cache as a backchannel. |
39 |
> |
40 |
> Note: I'm not an expert on any of this stuff, and if somebody wants to |
41 |
> chime in with details/adjustments to the above I'm all ears. |
42 |
> |
43 |
|
44 |
I think this is missing the point - this specific attack may be tied |
45 |
to BPF, but disabling BPF does not remove the underlying cause, which |
46 |
is speculatively executed instructions modifying the processor state. |
47 |
When news pieces are claiming that there is no way to fix this problem |
48 |
save changing the hardware or taking a huge execution penalty they are |
49 |
right. |
50 |
|
51 |
I am still working through the information myself, but it looks like |
52 |
BPF filters are an easy way to make sure you have something to look |
53 |
for in kernelspace. Since you have something to look for, you can then |
54 |
start asking yes or no questions about what is in cache that is |
55 |
mirroring kernelspace memory. Once you find it, you can start to look |
56 |
for other kernel structures that may contain more interesting |
57 |
information (private keys), and then ask questions like "are the bytes |
58 |
of the private key at position X equal to Y?" Eventually, you can read |
59 |
arbitrary memory. |
60 |
|
61 |
There are pieces claiming the details of the full attack allows |
62 |
writing to kernel memory, and I suspect it is far easier in practice |
63 |
to do the things detailed above. If AMD is not susceptible to one of |
64 |
the attacks, that is because speculatively executed instructions do |
65 |
not update the cache. But, if they do, |
66 |
|
67 |
It is likely we will need to wait for the full details to be released |
68 |
once the problem is addressed in secret. |
69 |
|
70 |
Cheers, |
71 |
R0b0t1 |