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

451–460 of 639 posts

Re: Reading privileged memory with a side-channel

#451

Post by user5994461 »

lsh123 wrote: post #399
PuffinBlue wrote: post #100

Earlier quoted context omitted.

The linked thread suggests that Spectre doesn't have _any_ mitigation. > The business/economic implications are not clear, since eventually the only way to eradicate the threat posed by Spectre is to swap out hardware. Is this fully accurate, there's no software mitigation available now? From [0], the above may be true: > There is also work to harden software against future exploitation of Spectre, respectively to pa…

There are possible mitigations for cloud providers: 1) pay $x / hour and run on shared machine with possibility of an attack; 2) pay $y / hour (where x Moreover the option 2) already exists for large customers and security sensitive applications (e.g. CIA dedicated cloud built by Amazon).

Amazon instances can be created with the dedicated flag. The host hardware will be dedicated to you, not shared with any other users. It should mitigate the attack.

The flag has a fixed fee in the thousands of dollars and each instance is 10% more expensive.

Re: Reading privileged memory with a side-channel

#452

Post by vanviegen »

jeremyjh wrote: post #421
jerrycruncher wrote: post #391

Earlier quoted context omitted.

"Turn of the century"? JS was used for little more than swapping images on mouseover and changing/"animating" title bar text back then. The "you will see absolutely nothing or a ream of {{blah}} text" without js enabled really only became prevalent in the last 5-or-so years. Even in the halcyon days of jQuery usage you could get around quite comfortably without js, as js was still being used to augment webpages rathe…

It wasn't common practice, but fully Javascript rendered applications were a thing as early as 2001. That was when my company developed the first one that I know of. It was a godawful ugly pig but it worked. Most sites did nothing like that, but they did use Javascript and would break in various ways without it. At that time, there were a lot of people admonishing web developers to test their applications with Javasc…

Before XHR, there was an iframe trick that could be used to the same effect. We were abusing that to do streaming updates (stalling requests until the server had new data) on then likes of IE5 back in 2004. WebSocket eat your heart out! :-)

Re: Reading privileged memory with a side-channel

#453

Post by gmueckl »

londons_explore wrote: post #350
gmueckl wrote: post #290

Earlier quoted context omitted.

There does not need to be a performance hit, but cache complexity must rise: speculative execution must use a separate cache for any data that was fetched speculatively. Only when that branch is truly accepted must that data enter the "real" cache. As long as speculative execution does not go on for too long, these secondary caches can stay really tiny (a handful of cache lines maybe).

The "speculation time" can be hundreds of cycles if you have a branch or memory read that takes a long time to resolve. This problem is already solved with speculative writes to main memory - a speculative store buffer keeps a sequence of memory operations which need to be done when the operation retires. These buffers are very power hungry, because every future speculative read must check every entry in the speculat…

What you are describing is sinply plain associative memory. If I remember correctly, this is complex in its imolementation, but does not grow exponentially. Plesse correct me if I am wrong.

Re: Reading privileged memory with a side-channel

#455

Post by nasredin »

teraflop wrote: post #221
ajasmin wrote: post #191

Earlier quoted context omitted.

Independent discovery don't happen overnight. Intel must have been aware of these vulnerabilities for some time. edit: I'm sure everyone involved acted responsibly. I'm just curious as how far apart these independent discoveries were made. The bug has been around forever, but it must have been discovered relatively recently since it's not fixed in hardware yet. I've always been baffled by the concept of simultaneous…

The Spectre paper includes this line in the acknowledgements: > We would like to thank Intel for their professional handling of this issue through communicating a clear timeline and connecting all involved researchers.

So Google people and the Germans were working on the same thing without knowing of each other until Intel connected them?

Re: Reading privileged memory with a side-channel

#456

Post by comex »

user5994461 wrote: post #447
comex wrote: post #337

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. For variant 1, you would need to find some legitimate kernel code, accessible by syscall, that looks at least somewhat similar to the example in the Project Zero blog post: if (untrusted_offset_from_caller length) { unsigned char value = arr1->data[untru…

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

Re: Reading privileged memory with a side-channel

#457

Post by ilitirit »

fooker wrote: post #450
technics256 wrote: post #435

Earlier quoted context omitted.

Thank you for this. Would you say this applies to both Spectre and Meltdown, or one and not the other?

This is a general explanation of side channel attacks, as I understand.

A timing attack is one type of side channel attack. These types of timing attacks can also be used against poor/unsuitable crypto functions, or even some processes involving general computation e.g. If it takes longer to reject input A than input B, you can reason that input A is closer to the answer (similar to someone reading a paragraph until they reach the first error).

Other side-channel attacks can come in the form of analysing network data, power-consumption (CPUs use more power when they are "busier")... even noise (listen for when the fans start spinning up).

Re: Reading privileged memory with a side-channel

#458

Post by ComodoHacker »

gervase wrote: post #134
wslh wrote: post #64

Has Google the best security team in the world? It seems like Google security is in a complete different league. I cannot imagine how this impacts companies handling fiat money or cryptocurrencies in the cloud like Coinbase in AWS.

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

>their primary [0] goal is altruistic: ... making the internet and computing as a whole a safer place.

Which is, at the same time, highly rational: to secure their entire market.

It's nice to have big corp's incentives aligned with the public good. Too bad it happens so rarely.

Re: Reading privileged memory with a side-channel

#459

Post by bonzini »

jhallenworld wrote: post #248
simion314 wrote: post #201

Earlier quoted context omitted.

From the article it seems that is not 100% sure AMD and ARM are not affected by metldown, only that they could not trigger the issue, but authors mention this "However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed."

I would think that any sane implementation would not transmit privileged data to waiting instructions. Look at their Listing 2: Instructions 5 - 7 will be waiting for the privileged data from line 4 (they are not speculatively executed since they have a data dependency on line 4). So why is Intel releasing the privileged data to the waiting instructions? An answer could be that violation checking is delayed until ret…

> I would think that any sane implementation would not transmit privileged data to waiting instructions.

The point of VIPT caches is exactly to use data before all the checks are completed.

It's easy to judge the sanity of things ex post, but maybe it's not that easy if it took 20 years to find the issue.

Re: Reading privileged memory with a side-channel

#460

Post by valleyer »

asveikau wrote: post #432
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.

> 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. It seems like keeping untrusted code in a separate address space would be a suitable workaround? A lot of comments here seem to be implying that meltdown-style reading of separate address spaces is possible via…

No, the Spectre paper discusses cross-process attacks too. First, you use BTB poisoning to coerce the victim process to branch-mispredict to code of your choice (a "gadget"). You can get that code to load memory of your choice, which can be the code of shared libraries (which are usually loaded only once into physical memory for all processes). Then you can do timing attacks using the last-level cache to determine whether that memory is in cache.

It's certainly not easy, but it's doable.

Post reply on HN