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.
Extracting a key over only a few days pretty much is a killer, heck even a few months for a high value target is game over think what happens if you get the private key of a key internet service like Google or Facebook, not to mention .gov or .mil sites.
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.
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)?
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).
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).
AVX and esp. AVX2 warmup time is very well known. That's why they tried it over this path at first. But you could use normal instructions also, it's just slower to extract keys.
16 comments
[ 1.5 ms ] story [ 41.8 ms ] threadI understand the original spectre exploit. But have no idea how it can be done 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.
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)?
Run some scripts, check on it six months later...oh look, we have SSL private keys for the X domains now.
https://news.ycombinator.com/item?id=17621823
Posted link doesn't add anything new.