can the spectre security vulnerability be in a virtual machine?

Question

Is it possible that a virtual machine like VirtualBox has the security vulnerability "spectre"? I think the VM maybe does out-of-order execution, but in my opinion it is not possible to peek at the cache to read the result.

Is there any explanation how it is possible to read the cache of a virtual cpu?

Answer 1

Yes Spectre can cross host/guest, guest/host and guest/guest boundaries because this is a CPU level flaw that means that potentially sensitive information can be leaked across anything that runs on a CPU core.

Most of the news stories on the internet speak about the cloud providers being worst hit by this as they have massive clusters of systems that are virtualised and could potentially be abused to leak sensitive information.

Most of the large providers should have been patched against the flaws by now, as best they can be, but this is going to be a problem that lives with us for some time.

Security.SE has a canonical Q & A regarding this and it mentions VM's:

I am running a Virtual Machine/Containers, to what extent am I vulnerable?

As per Steffen Ullrich's answer

• Meltdown attacks do not cross VMs, only leaks kernel memory to local processes.
• Spectre can work across VMs.

Also, from Steffen again, Meltdown and Spectre works with containers, as containers relies on the host kernel.

VMs use the actual CPU in your system with some privileged instructions trapped and able to be redirected. It uses the same caches and instructions as the host does. It is essentially just another layer within the physical CPU in your system.

Virtualization is only fast because it uses the physical CPU with as little abstraction as possible and relies on CPU hardware to provide isolation. Things like qemu can do emulation which would be safer as it is not a hardware CPU, but it is much slower and is different from virtualization.

From the Security.se canonical post again:

Spectre works on a different level and does not allow access to kernel-space data from user-space. In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result (if -> true), that results in asking for an out-of-bound memory access that the victim process would not normally have requested, resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way, memory belonging to the victim process is leaked to the malicious process.

So, because the VM runs in actual CPU hardware and all it needs to do is run a particular loop to "train" the speculative execution engine. Then it can use precise timing to watch the caches for particular patterns of access indicative of the host or guest (or other VM) process that it is looking to exploit.

In this way it means that a machine is exploitable in every direction. From host to VM, from VM to host, and from VM to VM.

Yes, it is by no means easy and is a difficult thing to pull off as the VM CPU core could change at whim of the host and the host could happily schedule tasks on different cores as well, but over a long period of time enough information could be leaked to give up a secret key to some important system or account. Given enough time and some suitably stealthy software everything is potentially open.

If you wanted a "secure" VM then you have to guarantee that it's cores are isolated. The only real ways to block this attack would be to "force" the host and VMs to only use certain cores so that they are never running on the same hardware but this would lead to an effective increase in cost as you would not be able to have as many VMs on a given host. You would never be able to get away with running more VMs than you have cores available, which is something I would expect to be done on "low load" servers as many systems sit idle for 90% of their life.

Answer 2

gem5

If you are interested in studying / reproducing vulnerabilities purely with emulation, without using the host CPU, I don't think QEMU is detailed enough to observe them as it does not simulate the CPU pipeline.

gem5 however, is used to estimate system performance in research and development, and does simulate enough CPU internals for you to observe Spectre in a fully clean and controlled environment.

A cool x86_64 demo with visualization has been published at: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

The downside of gem5 is that it is much slower than QEMU the simulation is more detailed.