"ZombieLoad": a new set of speculative-execution attacks

Posted May 21, 2019 16:24 UTC (Tue) by nix (subscriber, #2304)
In reply to: "ZombieLoad": a new set of speculative-execution attacks by excors
Parent article: "ZombieLoad": a new set of speculative-execution attacks

In the context of Spectre, there's also the NetSpectre attack, which explains how you can attack a remote target by sending not-even-vaguely-code-like data to the target system. You just send some requests that trigger a speculative array read based on secret data, which leaks into the cache state, then measure the cache state via the latency of network responses. The only way to truly solve that problem (without disabling speculation) is to disconnect from the internet entirely. Limiting the expressivity of data won't help.

You can also solve it by measuring the average latency of responses, then adding artificial latency and jitter that are much larger than the observed value. However, non-attackers aren't likely to be very happy with this, and non-attackers are indistinguishable from attackers :(

"ZombieLoad": a new set of speculative-execution attacks

Posted May 21, 2019 18:37 UTC (Tue) by excors (subscriber, #95769) [Link]

An attacker can always measure the latency of more responses and average out the jitter. So you're still not truly solving the problem, you're just making the attacks much slower.

I accept that making attacks much slower can still be worthwhile in practice; security doesn't require perfect solutions. You can try to calculate how many requests the attacker would have to make to average out the level of jitter you're adding and extract one bit of secret data, and decide how many bits the attacker needs to extract for a meaningful attack, and how many requests per second they can do, etc. If the cost to the attacker is greater than the value they would get from attacking you, with a safety margin of a few orders of magnitude, then you've probably done enough. But that's a complicated decision process and involves a lot of estimating and you'll probably get the numbers very wrong, so it's nowhere near as good as properly fixing the vulnerability so that you don't even need to think about it.

The annoying thing about Spectre is that it revealed a whole class of extremely complicated things you need to think about. Every patch in the kernel or microcode or hardware to mitigate the problem is just making the situation even more complicated to think about, and it will only stop when it's so immensely complicated that researchers give up trying to find new speculative-execution attacks and pick on easier targets.