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

Re: Reading privileged memory with a side-channel

#261

Post by tankenmate » Thu, Jan 04, 2018, 12:57 AM UTC

tankenmate wrote: post #215

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…

I'm not sure I see how to use the Spectre attack on AMD without running in kernel context. What am I missing?

I should clarify I mean user to root privilege escalation.

I totally understand how the breaking out of the javascript sandbox attack works and the fact that IPT won't help with that. With Linux's clone(), you could clone without CLONE_VM and use CLONE_NEWUSER|SYSVMSEM and then unmap everything except the Javascript interpreter / JIT and leave a shared memory map and communicate only via the shared memory map and SYSV semaphores for synchronisation. Obviously this wouldn't be available on other platforms.

Re: Reading privileged memory with a side-channel

#262

Post by jerf » Thu, Jan 04, 2018, 12:57 AM UTC

mtanski wrote: post #185

AndrewBissell wrote: post #111

Earlier quoted context omitted.

Yeah I was wondering this myself. Even if there's some fiddly hardware fix to make speculative execution secure, how much of its performance gains will we have to give up to get there?

Speculative execution as a concept should not be flawed. My take is that the results of illegal speculation should never be leaked in a visable way.

I can imagine some ways to armor the branch predictor, similar in principle to how languages like Perl have to include a random seed in their hash code (in some circumstances) to avoid being able to pre-compute values that will all hash to the same thing [1]. There should be some ways to relatively cheaply periodically inject such a randomization into the prediction system enough to prevent that aspect of the attack. This will cost something but probably not be noticeable to even the most performance-sensitive consumers.

But no solution leaps to mind for the problem of preventing speculative code from leaking things via cache, short of entirely preventing speculating code from being able to load things into the cache. If nobody can come up with a solution for that, that's going to cost us something to close that side channel. Not sure what though, without a really thorough profiling run.

And I'd put my metaphorical $5 down on someone finding another side channel from the speculative code; interactions with changing processor flags in a speculative execution, or interaction with some forgotten feature [2] where the speculation ends up incorrectly undone or something.

Yuck.

[1]: https://blog.booking.com/hardening-perls-hash-function.html

[2]: https://www.youtube.com/watch?v=lR0nh-TdpVg - The Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation (Dec 29, 2015)

Re: Reading privileged memory with a side-channel

#263

Post by Havoc » Thu, Jan 04, 2018, 12:58 AM UTC

Filligree wrote: post #224

Havoc wrote: post #183

So what exactly are they going to do about spectre? Seems pretty unstoppable from what I can see. Can they disable speculative exec completely for sensitive boxes or is this too baked in?

There's no mitigation. We'll need new CPUs. Meanwhile, don't ever run untrusted code in the same process as any kind of secret. Better yet, don't ever run untrusted code.

>We'll need new CPUs.

I don't think that's an option either.

Re: Reading privileged memory with a side-channel

#264

Post by [deleted] » Thu, Jan 04, 2018, 12:58 AM UTC

kibwen wrote: post #243

dannyw wrote: post #237

Earlier quoted context omitted.

The mitigations are to disable SharedArrayBuffer and severely round performance.now(). Not good that there aren’t other less intrusive ways to mitigate.

I don't get the impression that those are the full extent of the changes though; I think those two were called out only because they're API changes rather than implementation details. Haven't checked the code so I could be wrong, of course.

[deleted]

Re: Reading privileged memory with a side-channel

#265

Post by alexpersian » Thu, Jan 04, 2018, 1:00 AM UTC

swampthinker wrote: post #24

"Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host." Holy shit.

Was this quote removed from the article? I'm no longer able to find it.

Re: Reading privileged memory with a side-channel

#266

Post by Symmetry » Thu, Jan 04, 2018, 1:00 AM UTC

blattimwind wrote: post #123

cesarb wrote: post #91

Earlier quoted context omitted.

You know it's a bad one when Project Zero allows more than its usual 90-day deadline...

"Which systems are affected?" – "All systems." – "Come again?"

If you're using an in order processor, a Nexus 9 tablet say, then you should be safe.

Re: Reading privileged memory with a side-channel

#267

Post by voidmain » Thu, Jan 04, 2018, 1:01 AM UTC

theptip wrote: post #194

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 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 any really serious timing channel attacks, which... seems to have been disproved. Why isn't SharedArrayBuffer already being disabled as a stopgap? I think users can turn it off in firefox, how about Chrome?

Re: Reading privileged memory with a side-channel

#268

Post by thisacctforreal » Thu, Jan 04, 2018, 1:01 AM UTC

jwilk wrote: post #239

kibwen wrote: post #233

Earlier quoted context omitted.

> Am I overreacting here? Still skimming the paper, but the JS attack appears to be processor-intensive (please chime in if you interpret it differently!). Any widespread, indiscriminate use of such an attack in the wild seems like it would eventually be detected as surely as client-side cryptocurrency mining was discovered. If you aren't a valuable target, if you don't visit sites that are shady enough to discreetly…

And if you're a web developer, now it the good moment to make sure your site works correctly when JS is disabled.

Yes please!

Long live progressive enhancement and graceful degradation.

At least until we get a JS interpreter with proper permission controls and sandbox limits. Something closer to how Lua is embedded sounds nice.

Re: Reading privileged memory with a side-channel

#269

Post by rofex » Thu, Jan 04, 2018, 1:01 AM UTC

hrpnk wrote: post #86

richadams wrote: post #41

https://spectreattack.com/ Information site with some more information, and links to papers on the two vulnerabilities, called "Meltdown" and "Spectre" (with logos, of course). ( https://meltdownattack.com/ goes to the same site)

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?

Re: Reading privileged memory with a side-channel

#270

Post by kibwen » Thu, Jan 04, 2018, 1:02 AM UTC

drdrey wrote: post #257

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?

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 a variable number of processes.