Reading privileged memory with a side-channel • Hacker News Board

Re: Reading privileged memory with a side-channel

#611

Post by usrusr » Fri, Jan 05, 2018, 1:22 PM UTC

hyperion2010 wrote: post #596

wvenable wrote: post #592

Earlier quoted context omitted.

What I don't understand is how the branch predictor is even exploitable from JavaScript -- it doesn't have pointers. How can it "request" arbitrary memory locations and time the results?

It has byte arrays and indexing on those which is equivalent to having pointers. See page 6 and 7 of the Spectre paper.

So the mid-term fix for js jits should be to gimp indexed array access to the point where an out of bounds index value can never enter speculative execution, right? I'm no expert in these low-level things, but I imagine that speculative execution happens only from conditional jumps and that alternative bounds assurances (e.g. using base+idx%len as the eventually address or limiting it to a sandbox-owned region using a few bitmasks) should be possible that reliably stall the pipeline without allowing speculative access (obviously at considerable performance cost, but the jit should be able to whitelist certain safe access patterns and/or trusted code sources to not let this get out of hand). Am I missing something?

Re: Reading privileged memory with a side-channel

#612

Post by delaaxe » Fri, Jan 05, 2018, 2:09 PM UTC

Can someone show me an example of JavaScript code running in a browser that would display a password stored in kernel space?

Websites like the Guardian report that this is now the case but I don't understand how that's possible.

Re: Reading privileged memory with a side-channel

#613

Post by rurban » Fri, Jan 05, 2018, 2:53 PM UTC

richardwhiuk wrote: post #431

rurban wrote: post #200

Earlier quoted context omitted.

Only on Intel. Others restrict prefetches on permissions. I think this might even be fixed by microcode patches on Intel, at least os specific, looking at the first address bit.

If they could have done microcode patches they would have done, suggesting they can't.

Suse already has them.

I guess Intel only focused on Windows NT for several months, and there it's not so easy as on Linux.

Re: Reading privileged memory with a side-channel

#614

Post by mdavidn » Fri, Jan 05, 2018, 3:38 PM UTC

delaaxe wrote: post #612

Can someone show me an example of JavaScript code running in a browser that would display a password stored in kernel space? Websites like the Guardian report that this is now the case but I don't understand how that's possible.

The kernel maps itself into the address space of each process as an optimization to increase the performance of system calls. So yes, it is possible.

Re: Reading privileged memory with a side-channel

#615

Post by delaaxe » Fri, Jan 05, 2018, 4:04 PM UTC

mdavidn wrote: post #614

delaaxe wrote: post #612

Can someone show me an example of JavaScript code running in a browser that would display a password stored in kernel space? Websites like the Guardian report that this is now the case but I don't understand how that's possible.

The kernel maps itself into the address space of each process as an optimization to increase the performance of system calls. So yes, it is possible.

So, which functions would you have to call? How would you read the secrets? You can't do any kind of pointer magic in JS (nor system calls).

Re: Reading privileged memory with a side-channel

#616

Post by PeterisP » Fri, Jan 05, 2018, 4:10 PM UTC

diyseguy wrote: post #355

ErikAugust wrote: post #209

Earlier quoted context omitted.

I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?

At its core both vulnerabilities are essentially privilege escalation bugs (i.e. a random process can read e.g. secret keys from another process), but the Javascript case is the one that makes it remotely exploitable.

Re: Reading privileged memory with a side-channel

#617

Post by PeterisP » Fri, Jan 05, 2018, 4:12 PM UTC

diyseguy wrote: post #355

ErikAugust wrote: post #209

Earlier quoted context omitted.

I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?

At its core both vulnerabilities are essentially local privilege escalation bugs (i.e. a random process can read e.g. secret keys from another process), but that still is a very important exploit - if I can run unprivileged C code on e.g. AWS and are able to read the memory of someone else running on the same shared machine, that's really bad.

The Javascript case is the main one that makes it remotely exploitable.

Re: Reading privileged memory with a side-channel

#618

Post by PeterisP » Fri, Jan 05, 2018, 4:16 PM UTC

bonzini wrote: post #539

contrarian_ wrote: post #525

Earlier quoted context omitted.

> New CPU microcode is enough What would that entail? Disabling speculation completely? Disabling memory accesses during speculation?

Disabling indirect branch prediction (and thus speculation after indirect branches) while in kernel mode, or flushing the indirect branch predictor on kernel mode entry. Both need OS support in addition to the microcode, but the change is less invasive than PTI.

Wouldn't that be a serious performance hit?

Re: Reading privileged memory with a side-channel

#619

Post by Sean1708 » Fri, Jan 05, 2018, 5:12 PM UTC

comex wrote: post #605

Sean1708 wrote: post #540

Earlier quoted context omitted.

> For variant 1, a kernel JIT is definitely helpful, which is why the Project Zero PoC used it, but it's not required. If I'm understanding the post correctly it says that JIT's not required for Intel CPUs, but is required for AMD.

Their particular exploit for variant 1, which uses eBPF, only worked on AMD with the eBPF JIT, i.e. it did not work with the eBPF interpreter. But there are many other potential avenues to exploit that variant which have nothing to do with BPF. The result does suggest that it may generally be harder to trigger variant 1 on AMD processors (because they doesn't speculate as much?), but harder ≠ impossible.

Ah ok, thanks for clarifying.

Re: Reading privileged memory with a side-channel

#620

Post by pgt » Fri, Jan 05, 2018, 6:03 PM UTC

hyperion2010 wrote: post #430

An analogy that was useful for explaining part of this to my (non-technical) father. Maybe others will find it helpful as well. Imagine that you want to know whether someone has checked out a particular library book. The library refuses to give you access to their records and does not keep a slip inside the front cover. You can only see the record of which books you have checked out. What you do is follow the person…

Fantastic explanation of cache timing attacks. This morning I was explaining spectre to non-technical people and let me tell you, "leaking L1 CPU cache memory," is a real party starter. So I'm using there librarian example going forward.