Hey You Get Off of My Cloud Exploring

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 (2), Computer World, Data Center Knowledge, IT Business Edge, Cloudsecurity. org, Infoworld

Outline • Threats from VM placement in the cloud computing • EC 2 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 EC 2 (Elastic Compute Cloud) • Right. Scale • r. Path – Microsoft’s Azure Service Platform – Rackspace’s Mosso

More about EC 2 • • Virtual Machine Monitor (VMM): Xen Instance: A running OS image of virtual machine ECU: EC 2 Compute Unit ~= 1. 2 GHz Opteron/Xeon CPU Billing model: Charge based on lease duration, OS type, resource specifications, regions. – M 1. small: $0. 10/hour, 32 bit, 1 ECU, 1. 7 GB Mem, 160 GB Disk – C 1. medium: 32 bit, – M 1. large: $0. 40/hour, 64 bit, 2 ECU, 7. 5 GB Mem, 850 GB Disk – M 1. xlarge: 64 bit, – C 1. xlarge: 64 bit,

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 EC 2 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 coresident on the same physical machine? – Yes • Can an adversary launch instances that will be coresident with other user’s instances? – Yes • Can an adversary exploit cross-VM information leakage once co-resident? – Yes, possible but still very difficult

EC 2 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: ec 2 -75 -101 -210 -100. computer-1. amazonaws. com Internal IP: 10. 252. 146. 52 Internal Name: dom. U-12 -31 -38 -00 -8 D-C 6. computer-1. internal

EC 2 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 Dom 0 IP address only contains Dom 0 IP address. All /24’s between two consecutive Dom 0 /24’s inherit the former’s associated type. */24 is a subnet whose netmask is 255. 0.

What’s wrong? • Easy to management/charging – For M 1. 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 M 1. small VM. – Static IP assignment • No ones think it is a threat before.

Co-resident placement • Co-resident Decision Problem – Matching Dom 0 IP address • Send TCP SYN and set TTL small – Usually 3 hops, VM (Dom. U) -> Xen (Dom 0) -> VM (Dom. U) – Compare numerically close internal IP address • Use DNS to find external IP, IPExt • Run traceroute on a instance to IPExt, EC 2 will map IPExt to its internal IP, IPInt • 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.

EC 2 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.

EC 2 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 M 1. small instances was ever observed simultaneous running on the same machine. – Consistent with CPUID test • No co-residence was ever observed for m 1. xlarge and c 1. 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 Forty M 1. small victims launched by two accounts. (a third account for co-resident 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.

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 – Estimate victim’s work load • Cache • Network traffic – Keystroke timing attack • Require on the same core – Other cross-VM attacks Different Patterns • Use resource contention

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.