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

Re: Reading privileged memory with a side-channel

#601

Post by bspammer » Thu, Jan 04, 2018, 10:22 PM UTC

ErikAugust wrote: post #209

jotux wrote: post #115

Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.

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

Terrifyingly, this seems to work on a DigitalOcean droplet. I'm assuming this means people could potentially read memory from other VMs on the same system, albeit with a great deal of difficulty.

Re: Reading privileged memory with a side-channel

#602

Post by krylon » Thu, Jan 04, 2018, 10:26 PM UTC

I should at first point out that I am by no definition an expert on CPU design, operating systems, or infosec.

But I just remembered that years ago the FreeBSD developers discovered a vulnerability in Intel's Hyperthreading that could allow a malicious process to read other processes' memory.[1]

To the degree that I understand what is going on here, that sounds very similar to the way the current vulnerabilities work.

For a while, back then, I was naive enough to think this would be the end of SMT on Intel CPUs, but I was very wrong about that.

So I am wondering - is this just a funny coincidence, or could people have seen this coming back then?

[1] http://www.daemonology.net/hyperthreading-considered-harmful...

Re: Reading privileged memory with a side-channel

#603

Post by zipwitch » Thu, Jan 04, 2018, 11:44 PM UTC

rconti wrote: post #133

What are the odds that the NSA already knew about this? Roughly 100%?

I'm not familiar with the intricacies of CPU design. What are the odds the NSA somehow arranged for these vulnerabilities to exist?

Re: Reading privileged memory with a side-channel

#604

Post by notriddle » Fri, Jan 05, 2018, 12:04 AM UTC

kibwen wrote: post #270

drdrey wrote: post #257

Earlier quoted context omitted.

Doesn't each tab run in a separate process?

Chrome starts putting multiple tabs in the same process once certain resource thresholds are reached. There's an experimental "site isolation" option that you can toggle on to enforce this better, currently with some caveats: https://www.chromium.org/Home/chromium-security/site-isolati... . Curious to know whether Firefox has anything similar in the pipe, since it uses a fixed number of content processes rather than…

Yeah. https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

Re: Reading privileged memory with a side-channel

#605

Post by comex » Fri, Jan 05, 2018, 12:41 AM UTC

Sean1708 wrote: post #540

comex wrote: post #188

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

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

Re: Reading privileged memory with a side-channel

#606

Post by School-Cotton » Fri, Jan 05, 2018, 2:43 AM UTC

mwgalloway wrote: post #590

user5994461 wrote: post #463

Earlier quoted context omitted.

There was an announcement not long ago saying they are not insured.

Can you reference that? The CoinBase support page currently says crypto is insured against security breaches on their end.

Crypto in their hot wallets, or crypto in cold storage?

Re: Reading privileged memory with a side-channel

#607

Post by 314 » Fri, Jan 05, 2018, 3:04 AM UTC

lma21 wrote: post #598

314 wrote: post #537

Earlier quoted context omitted.

Your analogy is more apt for side-channel attacks in general. Here is a more specific version for Meltdown: A library has two rooms, one for general books and one for restricted books. The restricted books are not allowed out of the library, and no notes or recordings are allowed to be taken out of the restricted room. An attacker wants to sneak information out of the restricted room. To do this the pick up a pile of…

What is the analogy behind being able to go into the restricted room?

The restricted room is the part of the machine behind the protection. Memory reads are not checked at the tine access. They are checked when the instruction retires.

Re: Reading privileged memory with a side-channel

#608

Post by user5994461 » Fri, Jan 05, 2018, 4:26 AM UTC

comex wrote: post #456

user5994461 wrote: post #447

Earlier quoted context omitted.

>>> By "user to root privilege escalation", I'll assume you mean leaking kernel data without root, since this attack doesn't directly allow escalating privileges at all. The attack allows to read all the memory. Isn't there a way to scan for passwords or ssh keys and turn that into a privilege escalation?

Sure, SSH keys would probably work on a system with SSH enabled; I just wouldn't count that as "directly". (That would include most servers but exclude most Android devices; I have no idea whether there are other escalation methods for Android.)

Direct or indirect is meaningless at this point. The exploit is proven, they just have to determine the "best" memory locations to read to make something "useful" out of it. Then it's bundled together as an exploit kit and it's Armageddon.

Re: Reading privileged memory with a side-channel

#609

Post by prab97 » Fri, Jan 05, 2018, 6:57 AM UTC

myrmi wrote: post #510

prab97 wrote: post #480

Earlier quoted context omitted.

I don't understand how this info can be used for getting what was inside the book? If my understanding of your explanation is correct, book name is analogous to memory address. When the victim (legit process) returned the book with name X (called free on the mem block X), the librarian (OS) erased all pages of the book and repurposed it for printing another book before handing it out to the evil dude(snoopy process).

My attempt, assuming that the books only contain one character each: The librarian has a list of books you're not allowed to take out. You request one of those books (book X), but it takes a while for search to run to see whether you're allowed to or not. While you're waiting, you say "actually, I'm not really interested in taking out book X, but if the content of that book is 'a', I'd like to take out book Y. If the…

Thanks, this was a great explanation, really simplified it!

Re: Reading privileged memory with a side-channel

#610

Post by boulos » Fri, Jan 05, 2018, 11:22 AM UTC

mike_hearn wrote: post #527

boulos wrote: post #443

Earlier quoted context omitted.

Disclosure: I work on Google Cloud. If you run a multitenant workload on a linux system (say you're a PaaS or even just hosting a bunch of WordPress side by side) you should update your kernel as soon as is reasonable. While VM to VM attacks are patched, I'm sure lots of folks are running untrusted code side by side and need to self patch. This is why our docs point this out for say GKE: we can't be sure you're runni…

No offence intended as I'm sure it's a bit of a madhouse there right now, but is your statement really correct? I read the Spectre paper quite carefully and it appears to be unpatchable. Although the Meltdown paper is the one that conclusively demonstrated user->kernel and vm->vm reads with a PoC, and Spectre "only" demonstrated user->user reads, the Spectre paper clearly shows that any read type should be possible a…

Sorry for the confusion.

I have been most focused on people being concerned that a neighboring VM could suddenly be an attacker. You're right that the same kind of thing that affects your JavaScript engine as a user affects say Apache or anything that allows requests from external sources. However, that situation already has a much larger attack surface and people in that space should be updating themselves whenever there's any CVE like this.

My concern was that the Azure announcement made it sound like they've done the work, so nothing is required. That's not strictly true, even though providers have mitigated one set of attacks at the host kernel layer, so I wanted to correct that.