Hey, You, Get Off of My Cloud

earsplittinggoodbeeInternet και Εφαρμογές Web

3 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

48 εμφανίσεις

Hey, You, Get Off of My Cloud
:

Exploring Information Leakage in

Third
-
Party Compute Clouds

Yan Qiang
, 2009
-
1
-
7

Conference & Authors


CCS 09’


University of California, San Diego
, USA


Thomas Ristenpart, Hovav Shacham, Stefan Savage


Massachusetts Institute of Technology, Cambridge
, USA


Eran Tromer




Media coverage


MIT Technology Review, Network World, Network World
(2), Computer World, Data Center Knowledge, IT Business
Edge, Cloudsecurity.org, Infoworld

Outline


Threats from VM placement in the cloud
computing


EC2 cloud computing inside


Co
-
resident placement


Demo attacks by exploiting cross
-
VM
information leakage


Conclusion & countermeasure

Third
-
party cloud computing


A new business model


On
-
demand computing outsourcing


Large scale computer lease


Charge for the actual computation utilization


Amazon
’s
EC2

(Elastic Compute Cloud)


RightScale


rPath


Microsoft
’s
Azure

Service Platform


Rackspace
’s
Mosso


More about EC2


Virtual Machine Monitor (VMM):
Xen


Instance:
A running OS image of virtual machine


ECU:
EC2 Compute Unit

~= 1.2GHz Opteron/Xeon CPU


Billing model:
Charge based on lease duration, OS type,
resource specifications, regions.


M1.small
: $0.10/hour, 32bit, 1ECU, 1.7GB Mem, 160GB
Disk


C1.medium
: 32bit,


M1.large
: $0.40/hour, 64bit, 2ECU, 7.5GB Mem, 850GB
Disk


M1.xlarge
: 64bit,


C1.xlarge
: 64bit,

On demand Price

Reserved Price

*Extra Price will
be charged for
the amount of
data transfer
IN/OUT.

Threats from VM placement


Many threats have been there, this one is
unique for cloud computing.


The adversary may be able to
place

the malicious
instance on the
same

physical machine where the
victim instance reside through legal process.


Then launch certain
cross
-
VM

attacks


It is
quite trivial
but
firstly

mentioned in the
context of
highly hyped
cloud computing.


It is accepted by CCS and raises the interest of media

Research questions

(use EC2 as a case study)


Can one determine
where

in the cloud infrastructure
an
instance

is located?


Yes


Can one
easily

determine if two instances are
co
-
resident

on the
same

physical machine?


Yes


Can an adversary
launch
instances that will be
co
-
resident

with other user’s instances?


Yes


Can an adversary exploit
cross
-
VM

information leakage
once
co
-
resident
?


Yes, possible but still very difficult

EC2 cloud computing inside

(Zones)

Different availability zones use different IP regions.

Each instance has one internal IP and one external IP. Both are static.

For example:


External IP:
75.101.210.100


External Name:
ec2
-
75
-
101
-
210
-
100.computer
-
1.amazonaws.com


Internal IP:
10.252.146.52


Internal Name:
domU
-
12
-
31
-
38
-
00
-
8D
-
C6.computer
-
1.internal

EC2 cloud computing inside

(Instance Types)

The same instance type within the same zone uses similar IP
regions even for different accounts.

Mapping decision heuristic
:


A /24 inherits any included sampled instance type.


A /24 containing a Dom0 IP address only contains Dom0 IP address.


All /24’s between two consecutive Dom0 /24’s inherit the former’s associated type.


*/24 is a subnet whose netmask is 255.255.255.0.

What’s wrong?


Easy to management/charging


For
M1.small
, CPUID shows physical CPU has 2
CPUs, each with 2 cores, core usage limit is 50%
for an instance


A physical machine can hold
eight

M1.small VM.


Static IP assignment



No ones think it is a threat before.

Co
-
resident placement


Co
-
resident Decision Problem


Matching Dom0 IP address


Send TCP SYN and set TTL small


Usually 3 hops,
VM

(
DomU
)
-
>
Xen

(
Dom0
)
-
>
VM

(
DomU
)


Compare numerically close internal IP address


Use DNS to find external IP,
IP
Ext


Run
traceroute

on a instance to
IP
Ext
, EC2 will map
IP
Ext

to its internal IP,
IP
Int


Difference between internal IPs is within
7
.


Verified by side channel communications

Side channel communications

(Measure load latency)


Disk:
0.0005
bps


Sender


Send
1
: read a
random

position on shared disk


Send
0
: do nothing


Receiver


Read
1
:
long
read time for a
fixed

position


Read
0
:
short
read time for a
fixed

position


Cache:
0.2
bps

(noise
-
resistant by
differential coding
)


Sender


Send
1
: read all
odd

lines in the cache


Send
0
: do nothing


Receiver


Read
1
: time difference between reading all
odd

lines and
even

lines are
significant positive
.


Read
0
: remaining cases.


EC2 Placement Policy
(implied)


Placement locality


Sequential placement locality


Two instance run
sequentially

are often assigned to the
same

machine (one starts after one terminated).


Parallel placement locality


Two instance from
distinct

accounts run roughly at the
same

time are often assigned to the
same

machine.


The key point is to catch the time point


On
-
demand service will not always be online.


Try to launch a malicious instance immediately after victim
instance is re
-
launched.

EC2 Placement Policy
(implied)


Load balance sparseness


Load balance sparseness


Different instances of the
same

account was never observed
simultaneous

running on the
same

machine.


No more than
eight

M1.small

instances was ever observed
simultaneous

running on the
same

machine.


Consistent with CPUID test


No
co
-
residence was ever observed for
m1.xlarge

and
c1.xlarge

instances.


Consistent with CPUID test


Brute force is possible. (8.4%
-
> 40.0% when watching)


Just find out proper
zone
and
instance type
and keep trying.


Max
20

simultaneous instance for an account.

Effects of placement exploits

Increased time lag after victim launched does not affect too much when
exact region and instance type are known in the experiments.

Placement locality has a strong impact.

Forty
M1.small

victims launched by two accounts.

(a third account for co
-
resident exploits)

Demo attacks by exploiting cross
-
VM
information leakage


After place the malicious instance on the same
physical machine where the victim instance
resides,


Denial of service


Use resource contention


Estimate victim’s work load


Cache


Network traffic


Keystroke timing attack


Require on the same core


Other cross
-
VM attacks


Different Patterns

Conclusion & countermeasure


They identified the
fundamental risk
arise from
sharing

physical infrastructure between mutually
distrusted

users,


even when their actions are isolated through
virtualization techniques.



Suggested countermeasure:


Let users
choose

their VM placement policy and let
them
pay

for their choices.


Additional cost will not exceed the cost of a single physical
machines.