Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reading privileged memory with a side-channel

googleprojectzero.blogspot.com

Post reply on HN
Print view View original

321–330 of 639 posts

Re: Reading privileged memory with a side-channel

#321

Post by theclaw »

dmm wrote: post #284
deckard1 wrote: post #276

Earlier quoted context omitted.

We'll have to dig a time machine out and go back to 1998 then. I'm being a facetious ass. But you know I'm not wrong, either.

You are wrong. Install the NoScript extension and you can see your site without js. NoScript also allows you to selectively enable js per site on a temporary or permanent basis. This is the default way that I and many other people browse the web. https://noscript.net/

That doesn't make the effort required of a developer to remove an existing JS dependency any easier, though, other than allowing them to see how the site breaks which can already be done using the F12 dev tools.

A lot of sites rely on JS to function even at a basic level these days and I think the parent was saying it's unlikely that that's going to change.

Re: Reading privileged memory with a side-channel

#322

Post by greenleafjacob »

Unklejoe wrote: post #281

Just an idea that I had: If these exploits seem rely on taking precise timing measurements (on the order of nanoseconds), could we eliminate or restrict this functionality in user space? The Spectre exploit uses the RDTSC instruction, and this can apparently be restricted to privilege level 0 by setting the TSD flag in CR4. I know it would kind of suck, but it might be better than nothing. I would think that most typ…

That is the approach Firefox is taking [1]:

> Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox.

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

Re: Reading privileged memory with a side-channel

#323

Post by londons_explore »

kibwen wrote: post #277
voidmain wrote: post #267

Earlier quoted context omitted.

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…

> I think users can turn it off in firefox, how about Chrome? This month's stable Chrome release will be outright disabling SharedArrayBuffer until additional mitigations are enacted.

Which sucks for people who've built sites which rely on it.

It isn't exactly polyfillable.

Re: Reading privileged memory with a side-channel

#324

Post by [deleted] »

Pyxl101 wrote: post #309

Is there any information available about whether the Linux KPTI patch mitigates the ability to use eBPF to read kernel memory? I'm asking because eBPF seems to execute within the kernel, and KPTI seemed to be about unmapping kernel page table when userspace processes execute. Are there any mitigations to the eBPF attack vector?

[deleted]

Re: Reading privileged memory with a side-channel

#325

Post by Pyxl101 »

buryat wrote: post #36
mrmondo wrote: post #13

"AMD chips are affected by some but not all of the vulnerabilities. AMD said that there is a "near zero risk to AMD processors at this time." British chipmaker ARM told news site Axios prior to this report that some of its processors, including its Cortex-A chips, are affected." - http://www.zdnet.com/article/security-flaws-affect-every-int... * Edit: From https://meltdownattack.com/ Which systems are affected by Mel…

That article links a commit [1] that contradicts this statement > AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. And Axios [2] that…

How does that pertain to the vulnerabilities that involve eBPF? My understanding is that eBPF code executes within the kernel, and so would run at the same privilege level.

Re: Reading privileged memory with a side-channel

#326

Post by civilitty »

jerf wrote: post #262
mtanski wrote: post #185

Earlier quoted context omitted.

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

AFAICT injecting any sort of delay that prevents this attack would also completely negate any benefit from caches and that would take us back to 2000s performance at best, even with 10-16 core Xeon monsters. The branch predictor is really just a glorified cache prefetcher so you'd not only have to harden the branch predictor but anything that could possibly access the cache lines that the branch predictor has pulled up.

Re: Reading privileged memory with a side-channel

#327

Post by eindiran »

static_noise wrote: post #103
chc wrote: post #79

Earlier quoted context omitted.

You mean without getting whomped for insider trading? I don't think they're allowed to do it in advance at all.

As far as I know they HAVE to register a trade in advance. I.E. three months ahead: "I will sell 600 shares on 15th of December if the share price is above 50". This information is public and other people can use this information before the trade actually happens.

It looks like he registered for the trade in October, well after Intel was made aware of the issue.

Re: Reading privileged memory with a side-channel

#328

Post by londons_explore »

mintplant wrote: post #155
013a wrote: post #148

Earlier quoted context omitted.

It probably means if you want mitigations right now, you can flip that flag. Otherwise wait for Chrome to auto-update with new versions that have mitigations enabled by default.

Would I be correct in assuming a browser-level mitigation isn't necessary if you're running a patched OS?

Your OS needs patching, as do any programs which handle secret stuff like passwords, cookies, or tokens and interact with the internet (ie. web browsers).

Re: Reading privileged memory with a side-channel

#329

Post by Pyxl101 »

deckard1 wrote: post #276
jwilk wrote: post #239

Earlier quoted context omitted.

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

We'll have to dig a time machine out and go back to 1998 then. I'm being a facetious ass. But you know I'm not wrong, either.

I browse with NoScript and quite a lot of the web works just fine, in fact. I can selectively enable JavaScript for sites that need it, and that I trust.

Re: Reading privileged memory with a side-channel

#330

Post by mirashii »

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.

A little bit more info can be found here [1]. In particular, site isolation [2] will also assist in protecting against this vulnerability.

[1] https://support.google.com/faqs/answer/7622138#chrome [2] http://www.chromium.org/Home/chromium-security/site-isolatio...

Post reply on HN