Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds

Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds. In 2009, Thomas Ristenpart and colleagues presented this work at the ACM Conference on Computer and Communications Security, commonly called CCS. They examined whether an attacker starting as an ordinary cloud customer could maneuver a probe virtual machine onto the same physical host as a target, then learn something across the virtualization boundary. Three distinctions clarify the result: arranging placement, confirming co-residence, and demonstrating controlled information leakage are not equivalent to stealing a customer’s secrets.

Two ideas organize the threat. Placement means getting a VM, which stands for virtual machine, onto particular physical infrastructure. Co-residence means that two VMs are running on the same physical host. The attacker is not assumed to begin with privileged access: the starting point is an ordinary customer account. The proposed attack therefore has two stages. First, obtain co-residence with the target. Second, extract information across the isolation boundary through shared resources such as caches or disks.

The investigation separates several questions that are easy to blur together. Can publicly observable network and allocation clues reveal enough about placement to guide launches? Can launch timing and configuration improve the chance of landing beside a chosen victim? Can the attacker confirm that both VMs share a host? Finally, can measurements from that position reveal target activity? This separation is operationally useful because successful placement is only access to a measurement position; it is not, by itself, proof that secrets can be recovered.

The researchers treated EC2 as a black box, meaning they worked without provider-internal placement data. They used public and internal IP addresses, availability zones, instance types, and network round-trip time to investigate placement. A disk-based covert channel—a deliberately created signal between controlled VMs—served as ground truth for same-host placement. Their broad experiment launched 1,785 probes across 18 days against 6,577 public HTTP servers. External checks were limited to public web ports, and the active tests avoided private-information access, vulnerability discovery, and disruption.

The broad launch strategy achieved co-residence for only a small percentage of eligible targets. In a focused locality experiment, 20 attacker probes reached roughly 40 percent probability of sharing a host with one recently launched victim, and additional probes produced diminishing returns. Success depended on matching the target’s cloud location and instance type, then launching at the right time. The researchers also induced third-party services to start their own controlled workload, then achieved co-residence with it.

The same-host test was checked against known controlled placements. Its disk message succeeded in 60 of 62 ordered co-resident pairings, with no false positives observed in that sample. Once beside a target, a cache-based covert channel carried about 0.2 bits per second, while the disk channel was far slower. The experiments also supported inference about workload and HTTP traffic. Keystroke timing was explored separately on a controlled test machine, not demonstrated against a live EC2 tenant.

The experiments did not recover a real customer’s key, password, or private data. Active channels involved controlled instances or the researchers’ own workload running through third-party services. The keystroke experiment also depended on a test-machine setup and assumptions about how often attacker and victim would share a processor core on EC2. The economic argument assumed access to additional accounts and rapid probe launches. Provider identity and billing controls, along with launch quotas and abuse detection, can constrain that assumption. Opaque scheduling also makes it specific to a provider and deployment rather than timeless.

For security architecture, it helps to distinguish hiding placement, reducing resource sharing, and eliminating physical co-residence. The researchers warned that obscuring placement clues could slow mapping without preventing side-channel tests for co-residence. Timing noise, cache clearing, and similar workload-specific defenses could be incomplete or expensive. They recommended customer placement controls and a sole-tenant option when unconditional protection from cross-VM channels was required. A broader industry interpretation is that confidential memory protection does not automatically conceal timing, access patterns, sibling-thread activity, or device side channels.

The contribution is a concrete attack chain: map cloud placement from outside, influence launches, verify same-host placement, and measure controlled leakage across the virtualization boundary. Cloud security architects and platform teams should examine which shared infrastructure can reveal co-tenancy or carry side-channel signals. Where that risk is unacceptable, they should consider dedicated tenancy. They should not treat the experiment’s old placement rates as forecasts for a current platform, or treat controlled leakage as evidence that an unrelated customer was compromised. The operational question is what sharing can be observed, not whether every shared service has been proved exploitable.