9

From a tweetstorm by security journalist Nicole Perlroth:

The most visceral attack scenario is an attacker who rents 5 minutes of time from an Amazon/Google/Microsoft cloud server and steals data from other customers renting space on that same Amazon/Google/Microsoft cloud server, then marches onto another cloud server to repeat the attack, stealing untold volumes of data (SSL keys, passwords, logins, files etc) in the process.

While Meltdown can be patched, my understanding is that there is no short term solution to Spectre. That seems to make this problem very, very bad. Wouldn't that spell the death of the whole bussiness? On the other hand, my natural instinct in these situations is usually to try to dismiss it as hype.

So:

  • If I have a sensitive service running in a public cloud such as AWS, should I panic and take it offline right away to stop my SSL keys from being stolen?
  • Is there anything cloud providers can do in the short to medium term to make their services reasonably safe?
  • Is there (or can there be) virtualization software that is not vulnerable to Spectre even though the host system is?
8

Spectre is far harder to use than Meltdown. In a cloud hosting situation, an attacker needs to know:

  • What software the target is using
  • Where in memory that software is
  • Where in memory the target data is
  • The behavior of the host CPU's branch predictor
  • The behavior of the host CPU's speculative execution system
  • and possibly some other things I'm forgetting

It's also much slower than Meltdown. (Meltdown can read protected memory at a rate of around 500 kbyte/sec under good conditions. The Spectre paper didn't give a speed, but the need to train the branch predictor for essentially each byte read means I'd expect a rate of single-digit bytes per second.)

Because of the difficulty in using it, Spectre can't usually be mass-deployed. I expect three-letter agencies will be making heavy use of it, but it's the sort of thing you'd use in a highly-targeted attack, where Meltdown is better suited for untargeted sweeps for interesting data.

In the short term, probably the best thing that hosting providers can do is make it easy for users to run their own software. A Spectre attack tuned for Apache 2.2.34 for Debian Wheezy on x86-64 is totally useless against Nginx, or against Apache 2.2.33, or against Apache 2.2.34 built with different compiler flags, or...

A fully virtualized system that emulates all aspects of the CPU should be immune to Spectre, but full virtualization is slow. Hardware-assisted virtualization may be vulnerable if branch-predictor training is shared between the VM and the host, while paravirtualization, sandboxing, and containers are completely vulnerable.

  • Great answer! So basically, my best protection is that I'm so boring the NSA wouldn't bother. – Anders Jan 4 '18 at 20:04
  • I'm not so sure that a fully virtualized system would be immune to Spectre. – aventurin Jan 14 '18 at 21:28
  • 1
    @aventurin, if you don't have direct access to the CPU, it's much harder to mis-train the branch predictor: not only do you need a suitable branch somewhere in the target program, you need a branch somewhere in the virtualization software with an equivalent address that you can exploit to do the training. – Mark Jan 15 '18 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.