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

1. Hey, You, Get Off of My Cloud:Exploring Information Leakage inThird-Party Compute Clouds Yan Qiang, 2009-1-7

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

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

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

5. 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,

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

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

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

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

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

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

12. 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, IPExt • Run traceroute on a instance to IPExt, EC2 will map IPExt to its internal IP, IPInt • Difference between internal IPs is within 7. • Verified by side channel communications

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

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

15. 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 eightM1.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.

16. Effects of placement exploits Forty M1.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.

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

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