Paper: Exploring Information Leakage in Third-Party Compute Clouds

At the end of last year, people from the University of California and MIT published an extremely interesting 14-pages paper about the risks of information leakage in multi-tenancy Infrastructure-as-a-Service (IaaS) clouds.
Titled Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds, it was presented at the ACM Conference on Computer and Communications Security 2009.

The research mentions The Rackspace Cloud (formerly Mosso), Microsoft Windows Azure, even if it doesn’t seem yet a IaaS platform, but it primarily focuses on Amazon Elastic Computing Cloud (EC2) describing how attack a target virtual machine inside the cloud in four phases:

  1. map the cloud provider’s internal infrastructure (“cloud cartography”)
  2. identify the attack target position
  3. place a hostile virtual machine in the same host of the target virtual machine
  4. perform side-channel attacks leveraging the shared resources

The paper claims that “investing just a few dollars in launching VMs, there’s a 40% chance of placing a malicious VM on the same physical server as a target customer”.

It ends with a number of suggestions to mitigate the risks:

First, cloud providers may obfuscate both the internal structure of their services and the placement policy to complicate an adversary’s attempts to place a VM on the same physical machine as its target. For example, providers might do well by inhibiting simple network-based co-residence checks.
However, such approaches might only slow down, and not entirely stop, a dedicated attacker. Second, one may focus on the side-channel vulnerabilities themselves and employ blinding techniques to minimize the information that can be leaked. This solution requires being confident that all possible side-channels have been anticipated and blinded. Ultimately, we believe that the best solution is simply to expose the risk and placement decisions directly to users. A user might insist on using physical machines populated only with their own VMs and, in exchange, bear the opportunity costs of leaving some of these machines under-utilized. For an optimal assignment policy, this additional overhead should never need to exceed the cost of a single physical machine, so large users—consuming the cycles of many servers—would incur only minor penalties as a fraction of their total cost.