Hey, You, Get Off of My Cloud:
Exploring Information Leakage in
Third-Party Compute Clouds
Thomas Ristenpart¤, Eran Tromer†, Hovav Shacham¤, and
Stefan Savage¤
¤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
Outline
Introduction
Treat Model & EC2
Network Probing
Cloud Cartography
Determining Co-Residence
Exploiting Placement EC2
Cross-VM Information Leakage
Conclusion & Future
References
Distributed System Lab.
2
Introduction
Third-party cloud computing represents the
promise to out-sourcing as applied to
computation.
The use of virtualization allows third-party
cloud providers to maximize the utilization by
a shared physical infrastructure.
New vulnerabilities:


It is possible to map the internal cloud
infrastructure.
We explore how such placement can then be used
to extract information.
Distributed System Lab.
3
Threat Model
We consider the provider and its
infrastructure to be trusted.
Adversaries are non-provider-affiliated
malicious parties.
Victims are users running confidentialityrequiring 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
service.
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
Amazon’s EC2
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
modes.
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
Network Probing
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.
The hypothesis:

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
Determining Co-Residence
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
machine.
Strong placement locality: Two instances run
sequentially are often assigned to the same
machine.
Distributed System Lab.
12
Exploiting Placement in EC2 (2)
Brute-forcing placement

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

Load measurement:
1. Prime: Read BUFFER at offsets of cache line size.
2. Trigger: Busy-loop until CPU’s cycle counter jumps by a large
value.
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
latencies.
High latencies = the sender is evicting the receiver’s data
form cache.
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
password.
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
distrustful users.
Future



Cloud providers may obfuscate both the internal
structure of their services and the placement
policy.
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
References
[1] 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
Q&A
Thank you!
Distributed System Lab.
20