Hey you get off of my cloud exploring information leakage in third party compute clouds
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

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


  • 149 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Hey you get off of my cloud exploring information leakage in third party compute clouds

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

Yan Qiang, 2009-1-7


Conference authors

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

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

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

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,


Hey you get off of my cloud exploring information leakage in third party compute clouds

On demand Price

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

Reserved Price


Threats from vm placement

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

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

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

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

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


Side channel communications measure load latency

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

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 implied1

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.


Effects of placement exploits

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.


Demo attacks by exploiting cross vm information leakage

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

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.


  • Login