At a recent conference I expressed concern about data leaking from one virtual machine to another running on the same host, or to the host system and its owners. There have been a number of papers exploring this possibility, including most recently some fine work using the shared hardware cache to obtain keys from another guest OS. [Zhang2012]

I have some basic security concerns about virtual machines: they draw the security perimeter at a strange place, between the kernel and the hardware. This relationship was generally assumed to be a cooperative one when kernels were designed. The kernel plays with certain registers, I/O ports, memory systems, and other hardware to support the user level processing. The hardware designers usually assumed that the kernel writers knew what they were doing.

This is not a complete generalization. A friend of mine in college managed (accidentally) to get the disk drive to repeated bang the disk heads against the disk spindle, a Very Bad thing to do. Hardware designers have to check their input, too.

But now we slip hypervisors into this interface, pretending to be the hardware. It is a powerful tool that goes back to the 1960s. But now our common CPUs have easy support, and virtual machines are legion.

The benefits are obvious: someone else deals with the hardware, power, air conditioning and other support issues. They do this in bulk, so we save on every CPU cycle. (Though prices at Amazon seem to be stubbornly resistant to moderation.)

But the security of these systems is problematic. Using the hardware/kernel interface is kludgy. It's a logical place to do it, but it is a complicated interface, and not originally designed with security in mind. And the common hypervisors tend to be huge, not a convincing argument for security. Implementing DOM0 with the Linux kernel is awfully heavyweight, and I support efforts to make tiny hypervisors, even with some formal methods to enhance their probably securiy.

Of course, there are other issues. One has to trust the hosting company, and the law enforcement agencies of the involved countries. There are hopes to keep the processing secure using encrypted disk files and homomorphic encryption, if we ever get that working.

I am not optimistic: it seems really hard, and will take someone smarter than me to figure out. But if they do, I am guessing it will degrade CPU performance so much that the virtual machine will lose its attraction. Even if it works efficiently, one assumes that the program counter will be accessible, giving rise to logic flow analysis, traffic analysis, and perhaps even a Kocher timing attack to extract secrets.

Okay, so all of this gets pretty theoretical. I expressed a subset of these concerns at the FedCyber conference, and an audience member said that he wished he had time to worry about such problems. He is much too worried about wrestling alligators to think about draining the swamp, much less future alligators.

I have encountered this response throughout my career, and have a lot of sympathy for it. IT people are a bit scarce, and have heavy loads. There isn't time to worry about these sorts of future threats. Management often considers such propeller-headed worries as theoretical, not worth much effort to deal with at the moment.

Should he worry about these things? To quote Yoda, "you will be!" Most of the theoretical attacks that my colleagues and I have discussed over the years have come to pass, and sometimes sooner than we guess. As a researcher, it is part of my job to think about these things.

For example, I have been giving password talks for over 20 years. I typically decry reusable passwords, recommending something like the old Securenet Key (long gone) or the SecurID token. The former was strictly challenge response, with a secret DES key. The latter is time based, and the shared keys are generated by RSA. I always said that the first approach was an epsilon better than the second, because the keys could be extracted from RSA. But both were clearly much better than passwords.

Well, as you know, we all learned that epsilon could have quite large values. This theoretical weakness caused major headaches and attacks.

And there are many other attacks that have moved from theoretical to actual. Sometimes you have to look for them, because their users keep them secret. Former theoretical attacks now have street names, like DDoS and APT.

So I wish I had answered the question with the warning to be careful about theoretical attacks. Someday there will be a street name for cross-VM attacks.

[Zhang2012] @inproceedings{Zhang:2012:CSC:2382196.2382230, author = {Zhang, Yinqian and Juels, Ari and Reiter, Michael K. and Ristenpart, Thomas}, title = {Cross-VM side channels and their use to extract private keys}, booktitle = {Proceedings of the 2012 ACM conference on Computer and communications security}, series = {CCS '12}, year = {2012}, isbn = {978-1-4503-1651-4}, location = {Raleigh, North Carolina, USA}, pages = {305--316}, numpages = {12}, url = {http://doi.acm.org/10.1145/2382196.2382230}, doi = {10.1145/2382196.2382230}, acmid = {2382230}, publisher = {ACM}, address = {New York, NY, USA}, keywords = {cache-based side channel, cross-vm side channel, side-channel attack}, }