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

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: External Name: ec computer-1.amazonaws.com Internal IP: Internal Name: domU D-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

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: 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.