Remote Spectre exploits demonstrated

https://lwn.net/Articles/761100/

by signa11 • 8 years ago

85 16 8 years ago

lwn.net

TekMol• 8 years ago

But can somebody ELI5 how the remote spectre exploit works?

I understand the original spectre exploit. But have no idea how it can be done without code being involved.

ithkuil• 8 years ago

without code being involved

When you perform a network request you cause code to be executed. The code on the server is designed to respond to the request, in the same way as any local cross-process call responds to a request (including a kernel system call).

The key difference is not in the trigger, but in the measurement: measuring cache timing effects is more tricky when you can only interact with the target machine via a relatively high latency (and highly variable latency) channel such as the network. The new attack here shows how this can still be done probabilistically.

If you wonder how you can flush the cache over the network (without code involved) the answer is the same ad the answer to this question: why can't spectre be solved by just restricting the ability to issue a cache flush instruction? You can effectively flush the cache by performing more requests that cause other stuff to be loaded in the cache and evicting the parts you want to be evicted.

Epskampie• 8 years ago

15 bits per hour... seems extremely low unless they are able to target the EXACT bits they need.

hobls• 8 years ago

This kind of attack is catastrophic in cryptography.

black_puppydog• 8 years ago

yeah, like, shortening a secret key by 15 bits per hour would save a looot of brute force...

rurban2• 8 years ago

Only on some popular OS which told you over all the years that kernel memory is safe to store keys. Of course it is not. They didn't listen, and it's getting worse.

sinatosk• 8 years ago

It can go up to 125 bytes per second, maybe more. I've not finished reading the pdf yet

jkabrg• 8 years ago

Attacks only get better over time. In a sense, there are security flaws in every computer program, which only get clearer with time. The issue here is that these flaws are in a CPU, which is a component that's very difficult to change, so the existence of security flaws (that will only become clearer over time) seems worse than if it were in software. Maybe it's worse because of economic reasons (all the computers we have today will become obsolete because of security problems) or maybe because it's impossible to mitigate the flaws (the bugs are physically part of the hardware).

Also I remember that cryptographers consider any leaking of information about a secret to be a break. They call this "semantic security". Maybe there's something special about crypto that means people have to be maximally paranoid. I wonder what level of paranoia is appropriate for CPUs.

Actually, if NetSpectre can already leak information about a plaintext or secret key, then that already breaks all of cryptography from some cryptographers' point of view.

Another thing: Nation states may learn how to execute Spectre attacks faster than academia does. Then again, those same nation states would also want to switch to non-Spectre-prone computers, which would be visible enough for other people to start changing. Or maybe I'm putting too much faith in the IT skills of nation states.

Given all that, I don't know what safety margin is appropriate for CPUs. When do we consider all of our CPUs to be broken? Is it when Spectre attacks are being used to extract our financial info en masse? Is it soon? Or is it when governments start changing their computers (assuming governments are even that clever -- see the NHS and Wannacry)?

matthew-wegner• 8 years ago

Depends on the level of automation possible in deploying a wide-scale attack, too.

Run some scripts, check on it six months later...oh look, we have SSL private keys for the X domains now.

robert_tweed• 8 years ago

This was discussed 3 days ago:

https://news.ycombinator.com/item?id=17621823

Posted link doesn't add anything new.

api• 8 years ago

Do spectre mitigations already out there fix this?

ajross• 8 years ago

In principle, yes. It's not a different exploit, it's just a different measurement technique for the timing (and one that most people wouldn't have expected to be possible).

loeg2• 8 years ago

Isn't the AVX warmup latency a novel mechanism not docuemnted in existing literature and therefore not mitigated? They also point out that lfence is not a total solution to preventing speculative access (and it isn't being adopted anyway since the performance cost is high).

Remote Spectre exploits demonstrated

Related Stories