Attack Steals Crypto Key From Co-Located Virtual Machines 73
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."
Don't trust hardware you don't own. (Score:5, Insightful)
"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.
Re:Don't trust hardware you don't own. (Score:5, Insightful)
Well a hypervisior is in theory a simpler beast than a operating system. Depending on your prespective it has less attack surface. I think thoes are good reasons to think we could get it right. The real source of trouble is the x86 world just does not provide the hardware isolation features needed.
Re:Hypervisor leaks cached data (Score:4, Insightful)
It appears that the hypervisor leaks data from one VM to another by not clearing a cache.
What is leaked is not actually the data in the cache; another virtual machine running on the same computer cannot access that data. What is leaked is some information about cache usage, which may then allow an attacker to find out what the other VM has been doing. The attacker fills the cache with data, switches to another VM, and when it gets control again, the attacker measures how long it takes to access the data that it put into the cache itself. If it's fast, then the attacker knows that the other VM hasn't touched that part of the cache. If it's slow, the attacker knows that the other VM touched this part of the cache.
Re:Who would have thought...... (Score:4, Insightful)
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.
Re:Don't trust hardware you don't own. (Score:3, Insightful)
I'm still confused as to why people believe that VMs are inherently secure
You're missing the point. No system is secure. What's nice about VMs is ... as many as you need, same price. So just chuck them often, don't even worry about checking them to see if they've been compromised. How awesome would it be if we could just destroy and replace physical desktops and servers 100 times a day? That would get expensive... but not with VMs, which allows you to move the security layer back to the image, and screw securing the actual running system.
Re:Don't trust hardware you don't own. (Score:4, Insightful)
When you can shift off that whole layer of complexity to a large-scale specialist, you've reduced the total complexity your company has to manage directly. Focus on the areas that matter, not the common ground. Did your company design, engineer, and build its own kitchen appliances for the company breakroom? Didn't think so...
Surely in handing over responsibility for managing that complexity, you also hand over control of what could be intensely critical components of your business. They may do a perfectly good job at a lower cost, but in the (hopefully infrequent) event that the shit hits the fan, the job of fixing it is out of your hands and out of your control and that ought to be scary.
I don't know. Maybe it makes enough sense in the bulk of cases to be a good plan, but the risk of having your entire infrastructure yanked out from under you because of a black swan event or just a regular-grade fuck-up at an unrelated company sounds like something best avoided.