Slashdot Mirror
Attack Steals Crypto Key From Co-Located Virtual Machines
Gunkerty Jeb writes "Side-channel attacks against cryptography keys have, until now, been limited to physical machines. Researchers have long made accurate determinations about crypto keys by studying anything from variations in power consumption to measuring how long it takes for a computation to complete. A team of researchers from the University of North Carolina, University of Wisconsin, and RSA Security has ramped up the stakes, having proved in controlled conditions (PDF) that it's possible to steal a crypto key from a virtual machine. The implications for sensitive transactions carried out on public cloud infrastructures could be severe should an attacker land his malicious virtual machine on the same physical host as the victim. Research has already been conducted on how to map a cloud infrastructure and identify where a target virtual machine is likely to be."
The published paper is an interesting read. Obtaining the crypto key to libgcrypt is only one application. In general, the authors say, it is possible to construct a side-channel attack on other, unrelated, processes in the attacked VM.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
"public cloud infrastructure". The very thought of that makes me cringe, then laugh at the absurdity of it.
We can't even code bug free operating systems. What makes anyone think we can code a bug free hypervisor? I'm still confused as to why people believe that VMs are inherently secure- are they secure because VMware/Xen/Oracle says they are? Or are they secure because they've been tried and tested in the fires of time? All I ever see about hypervisors these days is some inflated marketing terms or new "cloud" interoperability features or some other random junk that solves an imaginary problem someone first had to go out of their way to create. I've never seen anyone actually come out and say "This version of our hypervisor is even more secure then the last because of XYZ!".
The company I work for makes extensive use of "cloud influenced" features in-house. It's awesome to be able to two-click a LAMP stack into existence through a nice web portal or do the same for a couple of Win2K8 instances. Some idiot was preaching about outsourcing our hardware to someone else and putting everything "in the cloud". Luckily management saw it for the farce it was and put that guy in his place pretty quickly.
So again, I'm really curious as to why people explicitly trust: A) Their services/platforms to someone other then themselves, and B) expect that VM hypervisors are bullet proof.
All timing attacks are done in controlled conditions. This is extremely important. Most of them don't work well, if it all, in busy environments.
Bring a rubber hose !! Start with a "this is going up your nose unless" !! You can imagine the other places !! Leaves no marks !! Works every single time !! No IFS ANDS BUTTS !! Stupid, stupid boffins !! Always doing things the hard way !!
Typical the graphic reads sodom.
It appears that the hypervisor leaks data from one VM to another by not clearing a cache. If that is all, this leak can be fixed by explicitly clearing the cache when switching to another VM. This will probably cost a few CPU cycles (and cause a few extra cache misses when a VM is resumed).
You can find a more detailed blog post about this here:
http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html
This post gives a high-level summary of the attack:
http://blog.cryptographyengineering.com/2012/10/attack-of-week-cross-vm-timing-attacks.html
(I previously posted this as AC, but it vanished.)
No, it isn't since modern operating systems tend to isolate programs from each other, and in the case of this article the programs are even running in disparate virtual machines, which should put a wall between the two. It is only through exploiting the processor cache that the key could be extracted. The attacker monitors how the victim fills the instruction cache. Since the victim's crypto algorithm follows different code paths depending on the key, the researchers were able to determine key.
This kind of side-channel attack was not universally thought practical so this is news and would be good to think about how to mitigate this problem.
Why does everyone assume that the "Nation-State" is better at doing stuff like this than a private organization?
Remember, the best of the best don't work for government, because they can make much more money in the private sector, and the private sector has just as much motivation, if not more, to embark on this sort of activity than a Nation-State.
When I think of Nation-States, I think of incompetence, cutting corners, and operating under a set of political rules. I don't think of excellence and being the best in a field.
if the attacker has sufficient access to the host to study the vm's execution profile then i suspect the attacker can do a lot more than capture that key.. in the uses I would expect people to care about, web services running on a vm on the net, this implies that the attacker already has ssh access to the host machine. so an assumption of this vulnerability is that the host system is completely compromised. in such a case the attacker will have other options to get that key. as a side note, i dont know if it would be a good thing to fix this problem, you pay for perf for web servers so disguising the computation to mitigate such an attack would cost way more than it would achieve
just bind the cryptographically sensitive process to a dedicated processor.
In other words, this exploit requires: knowing what cryptographic software is being run, the presence of Xen and an apparent security hole therein, and lucky core colocation of the VMs in an environment that could easily have dozens of VMs running against more than a dozen cores "over the course of a few hours".
In short, all of this is unlikely to be reproducible outside of a lab.
It also appears that it doesn't work if there are more than two virtual machines running on the same physical CPU, or if the attacking VM is the only one running on a given CPU.
With 3 or more VMs on the same CPU, the cache gets populated by virtual machines other than the targeted "victim" machine, so the attacker doesn't know which is affecting what. And if the attacking VM is alone on the CPU, it can't find any other VMs to attack.
---------
There is inferior bacteria on the interior of your posterior.
Stop raining logic and reason when the sky is falling!
The StuxNet attack vector was probably thought of in the same way - until it was used. When there is a high value target, getting all the ducks in a row is not impossible, it's the reason professionals are called in. You only have to make it work once (though you have to avoid getting caught on all the other attempts).
A fool throws a stone into a well and a thousand sages can not remove it.
this exploit requires: knowing what cryptographic software is being run, the presence of Xen and an apparent security hole therein, and lucky core colocation of the VMs in an environment that could easily have dozens of VMs running against more than a dozen cores "over the course of a few hours".
It doesn't seem that far fetched to me. Call up the cloud provider as a customer and ask what technology they use. If they say Xen, go ahead, if not find another cloud provider.
Then you guess what cryptography software is likely to be in use. AES on LUKS is a very common setup. Since multiple VMs are likely to be sharing the same hardware, this increases your chance of a hit.
Then you wait. Yes, it might take a while for the two VMs to coincide on the same CPU, but it will happen.
Give me Classic Slashdot or give me death!
would be good to think about how to mitigate this problem.
Simple: Use a different core / cache for different VM instances... Oh, wait.
If necessary you could simply do unnecessary work on one of the code paths so that they end up doing the same amount of work on each path.
Suppose I have 4 build machines, each running a different OS or version of the OS. At any given time I only need to be building 1 version.
If I virtualize them, I can use one machine (with 4x the disk space). Even accounting for reliability (and getting better redundancy than before) I can get away with 2 machines instead of 4.
1. The Xen scheduler can be gamed and allows side-channel attacks.
2. Libgcrypt is not hardened against timing attacks and leaks information.
3. Signal processing is A Thing.
Speaking of side channel attacks ...
I have not done any formal experiments yet, but, according to the UNIX manual page for random(4), one of the sources for kernel entropy is hardware interrupts.
Because it's not clear to me that any hardware interrupts that exist, are truly random, in a virtualized machine ... it's not clear to me that VMs have the same level of randomness, as can be attained from interrupts occurring on an actual physical bus, servicing actual, diverse physical devices.
One workaround might be for the hypervisor to provide this from its own /dev/random but that would drain the hypervisor's pool of entropy more rapidly, weakening both hypervisor and virtual clients alike.
It would seem to me that the only robust solution to this would be for hypervisor motherboards to incorporate additional hardware, IE, a dedicated circuit that boosted the pool of entropy, say, monitoring the difference between the computer's internal and external temperatures - or background radiation, or something similarly unpredictable.
Or have I missed something?
~childo