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

301–310 of 639 posts

Re: Reading privileged memory with a side-channel

#301

Post by zetafunction »

theptip wrote: post #285
drdrey wrote: post #257

Earlier quoted context omitted.

Doesn't each tab run in a separate process?

That's true to first approximation in Chrome, but apparently not always. This recent article contains a bit more detail on Site Isolation: https://arstechnica.com/gadgets/2017/12/chrome-63-offers-eve... > Chrome's default model is, approximately, to use one process per tab. This more or less ensures that unrelated sites are kept in separate processes, but there are nuances to this set-up. Pages share a process if the…

Note that it's not just tabs sharing processes that's an issue: prior to the site isolation work, any iframe in the same page would always be in the same process as the main frame. With site isolation, it's possible to host cross-site [1] iframes in a separate process.

[1] Two pages are considered cross-site if they cannot use document.domain to become same origin. In practice, this means that the effective TLD + 1 component match.

Re: Reading privileged memory with a side-channel

#302

Post by caf »

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…

about:config javascript.options.shared_memory in Firefox.

Re: Reading privileged memory with a side-channel

#303

Post by chrisseaton »

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/

I think you’re misunderstanding. The person you’re replying to wasn’t saying you couldn’t disable JavaScript. They are saying the websites they and many in the industry develop won’t work like that and haven’t since the turn of the century. That’s what they were claiming to be not wrong about, and they aren’t. Turning on NoScript shows the problem but doesn’t solve it.

Re: Reading privileged memory with a side-channel

#304

Post by quotemstr »

j_coder wrote: post #198

Isn't possible for the kernel to patch all clflush instructions when the software is loaded to keep a circular list of all evicted addresses that would be evicted again on the interrupt that happens when the protected address is read? This way the the timing attack would not be possible.

clflush only makes the attack easier. There are other ways to flush the cache. Besides: code is mutable. You can just make a clflush instruction out of thin air without the loader's involvement.

Re: Reading privileged memory with a side-channel

#305

Post by justincormack »

Someone1234 wrote: post #74
infinity0 wrote: post #52

> We have some ideas on possible mitigations and provided some of those ideas to the processor vendors; however, we believe that the processor vendors are in a much better position than we are to design and evaluate mitigations, and we expect them to be the source of authoritative guidance. Intel: "Recent reports that these exploits are caused by a “bug” or a “flaw” [..] are incorrect." So much for "authoritative gui…

Arm also claims it is working as intended: > Arm recognises that the speculation functionality of many modern high-performance processors, despite working as intended, can be used in conjunction with the timing of cache operations to leak some information as described in this blog. I personally don't agree, but I guess they're trying to avoid needing to issue a recall for over ten years worth of CPUs?

They go into detail in the white paper https://developer.arm.com/-/media/Files/pdf/Cache_Speculatio...

They are adding a new instruction to control speculation...

Re: Reading privileged memory with a side-channel

#306

Post by JetSpiegel »

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

Worked on a Intel(R) Celeron(R) CPU 847 @ 1.10GHz.

With "gcc (GCC) 7.2.1 20171128", remove the parenthesis from CACHE_HIT_THRESHOLD macro[1] to compile correctly.

[1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...

Re: Reading privileged memory with a side-channel

#307

Post by hinkley »

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.

I wonder what fraction of data inside a kernel is really ‘private’.

Obviously we want 100% of the data in the kernel not to be writeable, but if only a small amount shouldn’t be accessible at all then maybe the long term solution is to handle that data in a special way. Something that makes using it slower but doesn’t make every other syscall suffer as much as a consequence.

Or maybe the solution is to prioritize moving more and more code into userspace.

Re: Reading privileged memory with a side-channel

#308

Post by mtanski »

bloorp wrote: post #217
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.

As I read through the meltdown paper, it looks really difficult to have the security we want and the performance we want at the same time. It's pretty crazy, but here's my limited understanding: There's a huge shared buffer between two threads. 256 * 4K. One thread reads a byte of kernel memory, literally any byte it wants, and it then reads one of those 4K pages from that buffer in order to cache that one memory pag…

After thinking about this I think you may be right. It might be hard (or impossible to do in practice).

> or within the same space as the executing address

That's probably a good place to start from. I'm guessing there still would be issues here with JITed code coming from a untrusted source.

Re: Reading privileged memory with a side-channel

#309

Post by Pyxl101 »

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?

Re: Reading privileged memory with a side-channel

#310

Post by ateesdalejr »

cesarb wrote: post #151
ateesdalejr wrote: post #108

So, basically CPUs will read instructions inside a branch even if the branch is eventually going to evaluate to false. Does the CPU do this to optimize branch instructions? The results of instructions that are executed ahead of time are stored in a cache. How exactly does this exploit read from the cache? I understand it uses timing somehow but I'm not quite sure exactly how that works. (I mostly do software.)

The cache in question is not something which stores the result of these speculatively executed instructions, but the normal L1-L2-L3 caches we are used to. The result of these instructions is discarded, but as a side effect, they may load something from memory into the cache. The exploit detects whether or not a particular memory address was loaded into the cache (reading from something already in the cache is much f…

Thanks for the helpful answer. :) Things make much more sense to me now.
Post reply on HN