Hey, You, Get Off of My Cloud:
Exploring Information Leakage in
Third-Party Compute Clouds
Thomas Ristenpart¤, Eran Tromer†, Hovav Shacham¤, and
¤Dept. of Computer Science and Engineering University of
California, San Diego, USA
†Computer Science and Artificial Intelligence Laboratory
Massachusetts Institute of Technology, Cambridge, USA
Distributed System Lab. 1
Treat Model & EC2
Exploiting Placement EC2
Cross-VM Information Leakage
Conclusion & Future
Distributed System Lab. 2
Third-party cloud computing represents the
promise to out-sourcing as applied to
The use of virtualization allows third-party
cloud providers to maximize the utilization by
a shared physical infrastructure.
It is possible to map the internal cloud
We explore how such placement can then be used
to extract information.
Distributed System Lab. 3
We consider the provider and its
infrastructure to be trusted.
Adversaries are non-provider-affiliated
Victims are users running confidentiality-
requiring services in the cloud.
Two kinds of attackers:
Those who are interested in being able to attack
some known hosted service.
Those focused on attacking a particular victim
Distributed System Lab. 4
The EC2 Service
To run Linux, FreeBSD, OpenSolaris and
Windows as guest operating system.
Those VMs are provided by a version of
the Xen hypervisor.
EC2 does not appear to currently
support live migration of instances.
Each user account is limited to 20
concurrently running instances.
Distributed System Lab. 5
Two “regions” at U.S. and one at Europe.
Three “availability zones” for each region.
“availability zones” are meant to specify
infrastructures with distinct and independent failure
There are five Linux instance types: ‘m1.small’,
‘c1.medium’, ‘m1.large’, ‘m1.xlarge’, and ‘c1.xlarge’.
Each instance is given Internet connectivity:
External IPv4 address and domain name.
Internal RFC 1918 private address and domain name.
Distributed System Lab. 6
We use nmap to perform TCP connect probes
To complete a 3-way hand-shake.
We use hping to perform TCP SYN traceroutes.
To send TCP SYN packets with increasing TTLs until no ACK is received.
We only targeted ports 80 or 443.
We used wget to retrieve web pages, but at most 1024 bytes.
Two types of probes:
External probes: It originates form a system outside EC2 to EC2’s instance.
Internal probes: It originates from an EC2 instance to another.
We use DNS resolution queries
To determine the external name of an instance.
To determine the internal IP address of an instance associated with some
public IP address.
Distributed System Lab. 7
Cloud Cartography (1)
‘map’ the EC2 service to understand:
Where potential targets are located in the cloud.
The instance creation parameters needed to attempt
establishing co-residence instance.
Different availability zones are likely to correspond to
different internal IP address ranges.
Two data sets:
One created by enumerating public EC2-based web servers
using external probes and translating responsive public IPs
to internal IPs.
Another created by launching a number of EC2 instances of
varying types and surveying the resulting IP assigned.
Distributed System Lab. 8
Cloud Cartography (2)
Surveying public servers on EC2
We performed: a TCP connect probe on port 80, a follow-up
wget on port 80, and a TCP port 443 scan.
Via an appropriate DNS lookup from within EC2, we
translated each public IP into an internal EC2 address.
One of the goals is to enable identification of the instance
type and availability zone of these potential targets.
Instance placement parameters
To launch instances by a single account, or two accounts.
The samples from each zone are assigned IP addresses from
disjoint portions of the internal address space.
A fuller map of EC2
Distributed System Lab. 9
Instance placement parameters
Distributed System Lab. 10
Instances are likely co-resident if they have
Matching Dom0 IP address,
Instance owner: the first hop on any route from it.
Uncontrolled instance: the last hop of a TCP SYN tranceroute to it.
Small packet round-trip times,
The first reported RTT in any probes was almost an order of magnitude
slower than subsequent probes.
Numerically close internal IP addresses
The same Dom0 IP will be shared by instances with a contiguous
sequence of internal IP address.
Veracity of the co-residence checks
If two instances can successfully transmit via the covert channel
then they are co-resident, otherwise not.
A hard-disk-based covert channel (under our control).
A TCP SYN traceroute to an open port on the target, and sees if
there is only a single hop.
Distributed System Lab. 11
Exploiting Placement in EC2 (1)
To say the attacker is successful if he
achieves good coverage (co-residence with a
notable fraction of the target set)
A single account was never seen to have two
instances running on the same physical
Strong placement locality: Two instances run
sequentially are often assigned to the same
Distributed System Lab. 12
Exploiting Placement in EC2 (2)
To run numerous instances over a long period of time and
see how many targets are co-residence.
Abusing placement locality
We assume an attacker can launch instances soon after the
launch of a target victim.
The attacker engages in instance flooding.
This suggests servers are often run on instances, terminated
when not need, and later run again.
Patching placement vulnerabilities
Let users request placement of their VMs on machines that
can only be populated by VMs from their accounts.
Distributed System Lab. 13
Cross-VM Information Leakage (1)
Measuring cache usage
1. Prime: Read BUFFER at offsets of cache line size.
2. Trigger: Busy-loop until CPU’s cycle counter jumps by a large
3. Probe: Measure the time for reading BUFFER at offsets of
cache line size.
Cache-based covert channel
Sender: To transmit “0” for idle, and frantically accesses
memory for “1”.
Receiver: To access memory and observes the access
High latencies = the sender is evicting the receiver’s data
Distributed System Lab. 14
Cross-VM Information Leakage (2)
Load-based co-residence detection
An adversary can actively cause load variation
due to a publicly-accessible service on the target.
Distributed System Lab. 15
Cross-VM Information Leakage (3)
Estimating traffic rates
Two m1.small instances
1000 cache load measurements in one instances
20 users (jmeter)
Web page is 3 Mb
Distributed System Lab. 16
Cross-VM Information Leakage (4)
Keystroke timing attack
The adversary’s goal is to measure the time
between keystrokes made by a victim typing a
We utilize the Prime+Trigger+Probe load
measurement technique to detect activity spikes
in an otherwise idle machine.
The same attack could be carried over to EC2,
except that this technique applies only to VMs
that timeshare a core.
Distributed System Lab. 17
Conclusion & Future
We argue that fundamental risks arise from
sharing physical infrastructure between
Cloud providers may obfuscate both the internal
structure of their services and the placement
One may focus on the side-channel vulnerabilities
and employ blinding techniques.
We believe that the best solution is simply expose
the risk and placement decisions directly to users.
Distributed System Lab. 18
 T. Ristenpart, E. Tromer, H.
Shacham, and S. Savage, “Hey, You,
Get Off of My Cloud: Exploring
Information Leakage in Third-Party
Compute Clouds.” In CCS, 2009.
Distributed System Lab. 19
Distributed System Lab. 20