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

Re: Reading privileged memory with a side-channel

#351

Post by tanilama » Thu, Jan 04, 2018, 2:37 AM UTC

kzrdude wrote: post #229

gervase wrote: post #134

Earlier quoted context omitted.

Project Zero is very well known for things exactly like this. Partially, it's because they are incredibly talented, but there are also talented people in academia and in other security consultancies. The biggest difference with Project Zero is that their primary [0] goal is altruistic: find vulnerabilities, and let people who can fix them know (vs publishing papers, securing paying clients, auctioning zero-days, etc)…

Hm that's tricky. These awesome findings didn't exactly provide net value for google, not even on the not so short term (next 10 years?). They've created a large problem for Google! :-)

Imagine the law suit if Google fails to detect this....

Re: Reading privileged memory with a side-channel

#352

Post by willsr » Thu, Jan 04, 2018, 2:37 AM UTC

kps wrote: post #272

rurban wrote: post #211

Earlier quoted context omitted.

Come on, Google completely "forgets" to mention the others, whilst the others do mention Google who detected it independently. And then look who wrote the papers, exploits and patches.

> Come on, Google completely "forgets" to mention the others Err… fourth paragraph: > Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at: Spectre (variants 1 and 2) Meltdown (variant 3)

Yuval Yarom's contribution (Flush+Reload) seems quite understated, considering how important it is to the attack.

Re: Reading privileged memory with a side-channel

#353

Post by humanjvm » Thu, Jan 04, 2018, 2:42 AM UTC

geertj wrote: post #349

What is the reason that Intel would allow speculative instructions to bypass the supervisor bit and access arbitrary memory? That seems the root cause for Meltdown. Is it that the current privilege level could be different between what it is now, and what it will be when the speculative instruction retires? If so then that seems a thin justification. CPL should not change often so it doesn't seem worth it to allow sp…

IIUC, these speculative instructions respect the current supervisor bit which was set by the previous faulting instruction.

Re: Reading privileged memory with a side-channel

#354

Post by londons_explore » Thu, Jan 04, 2018, 2:44 AM UTC

dgomesbr wrote: post #299

Great, embargo was in and google went ahead disclosing and saying hear we're here disclosing this (because they've patched)

3 or 4 people had bits of demo code up on twitter earlier today.

I implemented it myself simply based on the clues in the press release from AMD explaining why they weren't vulnerable. I don't even have a computer security background.

Re: Reading privileged memory with a side-channel

#355

Post by diyseguy » Thu, Jan 04, 2018, 2:44 AM 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...

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?

Re: Reading privileged memory with a side-channel

#356

Post by FranOntanaya » Thu, Jan 04, 2018, 2:45 AM UTC

Certhas wrote: post #207

jhallenworld wrote: post #187

Earlier quoted context omitted.

"Meltdown" is an Intel bug. "Spectre" is very bad news and affects all modern CPUs. Mitigation is to insert mfence instructions throughout jit generated sandboxed code making it very slow, ugh. Otherwise assume that the entire process with jit generated code is open to reading by that code. Any system which keeps data from multiple customers (or whatever) in the same process is going to be highly vulnerable.

After skimming the articles it sounds like a lot hinges on just how hard Spectre is to pull off in practice/in the wild. Anyone have any insights on that?

It doesn't look that hard, and in any case, we will suffer the mitigation consequences either way.

Re: Reading privileged memory with a side-channel

#357

Post by londons_explore » Thu, Jan 04, 2018, 2:47 AM UTC

phoe-krk wrote: post #161

bung wrote: post #11

Will patches for this eventually trickle down to things like LineageOS?

LineageOS is based on official Android sources. The moment the official Android kernel is patched, LineageOS will use the patch.

I like the way you say moment as if the android kernel is some single thing not a hodgepodge of hundreds of different kernels across tens of companies.

Re: Reading privileged memory with a side-channel

#358

Post by Pharaoh2 » Thu, Jan 04, 2018, 2:48 AM UTC

rofex wrote: post #269

hrpnk wrote: post #86

Earlier quoted context omitted.

Both domains were registered on 2017-12-22. Given the planned disclosure on 9th January that Google mentions and MS and others coding patches silently [1], do the early reports [2] of kernel patches, does this mean that due to coding in the open the whole disclosure procedure has been vastly accelerated? I wonder how the timing relates to New Year and many companies having holidays in CW1. [1] https://lists.freebsd.o…

Sorry to be daft, but hasn't the Google Zero team jumped the gun on the coordinated disclosure date by publishing their blog post 6 days in advance?

Some researchers had independently create and demonstrated working PoC based on the linux patches they saw which read kernel memory from user space. At that point it was already public.

After that its all about PR and getting people prepared for the magnitude and impact early.

Also to let people know that patches that were already available can be used (restarting GCP/AWS instances, SPI on chrome).

Re: Reading privileged memory with a side-channel

#359

Post by jncraton » Thu, Jan 04, 2018, 2:49 AM UTC

voidmain wrote: post #267

theptip wrote: post #194

Earlier quoted context omitted.

I think this means we should consider all browser processes to be completely insecure, until mitigations are applied (e.g. Chrome's Site Isolation: https://www.chromium.org/Home/chromium-security/ssca ). Looks like any session token/state could be exfiltrated from your Gmail tab to a malicious JS app running in-process, for example. Am I overreacting here?

It seems like practical attacks rely on having a reasonably precise timer available. The spectre paper uses SharedArrayBuffer to synthesize a timer, which is a recent and obscure feature: https://groups.google.com/a/chromium.org/forum/#!topic/blink... https://groups.google.com/forum/#!topic/mozilla.dev.platform... Chrome and Firefox's "intent to ship" posts both contain claims to the effect that there probably aren't…

SharedArrayBuffer will be disabled by default as a stopgap:

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

performance.now() accuracy is also being reduced.

Re: Reading privileged memory with a side-channel

#360

Post by f2f » Thu, Jan 04, 2018, 2:51 AM UTC

cfeeley wrote: post #279

One of the meltdown paper writers evidently has a sense of humor since "hunter2" [0] is one of the passwords they use in their demonstration [1] [0] http://bash.org/?244321 [1] https://meltdownattack.com/meltdown.pdf (page 13, figure 6)

hunter2 is the industry's accepted PoC password.