Virtual Machine Introspection (PowerPoint)

Document Sample
Virtual Machine Introspection (PowerPoint) Powered By Docstoc
					Hey, You, Get Off of My Cloud:
Exploring Information Leakage in
Third-Party Compute Clouds
Thomas Ristenpart¤, Eran Tromer†, Hovav Shacham¤, and
Stefan Savage¤
¤Dept. of Computer Science and Engineering University of
California, San Diego, USA
†Computer Science and Artificial Intelligence Laboratory
Massachusetts Institute of Technology, Cambridge, USA


                     Distributed System Lab.               1
  Treat Model & EC2
  Network Probing
  Cloud Cartography
  Determining Co-Residence
  Exploiting Placement EC2
  Cross-VM Information Leakage
  Conclusion & Future

               Distributed System Lab.   2
  Third-party cloud computing represents the
  promise to out-sourcing as applied to
  The use of virtualization allows third-party
  cloud providers to maximize the utilization by
  a shared physical infrastructure.
  New vulnerabilities:
     It is possible to map the internal cloud
     We explore how such placement can then be used
      to extract information.

                   Distributed System Lab.        3
Threat Model
  We consider the provider and its
  infrastructure to be trusted.
  Adversaries are non-provider-affiliated
  malicious parties.
  Victims are users running confidentiality-
  requiring services in the cloud.
  Two kinds of attackers:
     Those who are interested in being able to attack
      some known hosted service.
     Those focused on attacking a particular victim

                    Distributed System Lab.              4
The EC2 Service
  To run Linux, FreeBSD, OpenSolaris and
  Windows as guest operating system.
  Those VMs are provided by a version of
  the Xen hypervisor.
  EC2 does not appear to currently
  support live migration of instances.
  Each user account is limited to 20
  concurrently running instances.

              Distributed System Lab.   5
Amazon’s EC2
 Two “regions” at U.S. and one at Europe.
 Three “availability zones” for each region.
 “availability zones” are meant to specify
 infrastructures with distinct and independent failure
 There are five Linux instance types: ‘m1.small’,
 ‘c1.medium’, ‘m1.large’, ‘m1.xlarge’, and ‘c1.xlarge’.
 Each instance is given Internet connectivity:
     External IPv4 address and domain name.
     Internal RFC 1918 private address and domain name.

                      Distributed System Lab.              6
Network Probing
  We use nmap to perform TCP connect probes
      To complete a 3-way hand-shake.
  We use hping to perform TCP SYN traceroutes.
      To send TCP SYN packets with increasing TTLs until no ACK is received.
  We only targeted ports 80 or 443.
  We used wget to retrieve web pages, but at most 1024 bytes.
  Two types of probes:
      External probes: It originates form a system outside EC2 to EC2’s instance.
      Internal probes: It originates from an EC2 instance to another.
  We use DNS resolution queries
      To determine the external name of an instance.
      To determine the internal IP address of an instance associated with some
       public IP address.

                            Distributed System Lab.                               7
Cloud Cartography (1)
  ‘map’ the EC2 service to understand:
     Where potential targets are located in the cloud.
     The instance creation parameters needed to attempt
      establishing co-residence instance.
  The hypothesis:
     Different availability zones are likely to correspond to
      different internal IP address ranges.
  Two data sets:
     One created by enumerating public EC2-based web servers
      using external probes and translating responsive public IPs
      to internal IPs.
     Another created by launching a number of EC2 instances of
      varying types and surveying the resulting IP assigned.

                        Distributed System Lab.                  8
Cloud Cartography (2)
  Surveying public servers on EC2
     We performed: a TCP connect probe on port 80, a follow-up
      wget on port 80, and a TCP port 443 scan.
     Via an appropriate DNS lookup from within EC2, we
      translated each public IP into an internal EC2 address.
     One of the goals is to enable identification of the instance
      type and availability zone of these potential targets.
  Instance placement parameters
     To launch instances by a single account, or two accounts.
     The samples from each zone are assigned IP addresses from
      disjoint portions of the internal address space.
  A fuller map of EC2

                       Distributed System Lab.                  9
Instance placement parameters

            Distributed System Lab.   10
Determining Co-Residence
  Instances are likely co-resident if they have
      Matching Dom0 IP address,
         Instance owner: the first hop on any route from it.
         Uncontrolled instance: the last hop of a TCP SYN tranceroute to it.
      Small packet round-trip times,
         The first reported RTT in any probes was almost an order of magnitude
          slower than subsequent probes.
      Numerically close internal IP addresses
         The same Dom0 IP will be shared by instances with a contiguous
          sequence of internal IP address.
  Veracity of the co-residence checks
      If two instances can successfully transmit via the covert channel
       then they are co-resident, otherwise not.
      A hard-disk-based covert channel (under our control).
      A TCP SYN traceroute to an open port on the target, and sees if
       there is only a single hop.

                            Distributed System Lab.                             11
Exploiting Placement in EC2 (1)
  To say the attacker is successful if he
  achieves good coverage (co-residence with a
  notable fraction of the target set)
  A single account was never seen to have two
  instances running on the same physical
  Strong placement locality: Two instances run
  sequentially are often assigned to the same

                Distributed System Lab.     12
Exploiting Placement in EC2 (2)
  Brute-forcing placement
     To run numerous instances over a long period of time and
      see how many targets are co-residence.
  Abusing placement locality
     We assume an attacker can launch instances soon after the
      launch of a target victim.
     The attacker engages in instance flooding.
     This suggests servers are often run on instances, terminated
      when not need, and later run again.
  Patching placement vulnerabilities
     Let users request placement of their VMs on machines that
      can only be populated by VMs from their accounts.

                       Distributed System Lab.                 13
Cross-VM Information Leakage (1)
   Measuring cache usage
     Load measurement:
      1. Prime: Read BUFFER at offsets of cache line size.
      2. Trigger: Busy-loop until CPU’s cycle counter jumps by a large
      3. Probe: Measure the time for reading BUFFER at offsets of
         cache line size.
     Cache-based covert channel
         Sender: To transmit “0” for idle, and frantically accesses
          memory for “1”.
         Receiver: To access memory and observes the access
         High latencies = the sender is evicting the receiver’s data
          form cache.

                        Distributed System Lab.                         14
Cross-VM Information Leakage (2)
   Load-based co-residence detection
     An adversary can actively cause load variation
      due to a publicly-accessible service on the target.

                   Distributed System Lab.            15
Cross-VM Information Leakage (3)
   Estimating traffic rates
     Two m1.small instances
     1000 cache load measurements in one instances
     20 users (jmeter)
     Web page is 3 Mb

                  Distributed System Lab.        16
Cross-VM Information Leakage (4)
   Keystroke timing attack
     The adversary’s goal is to measure the time
      between keystrokes made by a victim typing a
     We utilize the Prime+Trigger+Probe load
      measurement technique to detect activity spikes
      in an otherwise idle machine.
     The same attack could be carried over to EC2,
      except that this technique applies only to VMs
      that timeshare a core.

                  Distributed System Lab.          17
Conclusion & Future
  We argue that fundamental risks arise from
  sharing physical infrastructure between
  distrustful users.
     Cloud providers may obfuscate both the internal
      structure of their services and the placement
     One may focus on the side-channel vulnerabilities
      and employ blinding techniques.
     We believe that the best solution is simply expose
      the risk and placement decisions directly to users.

                    Distributed System Lab.            18
  [1] T. Ristenpart, E. Tromer, H.
  Shacham, and S. Savage, “Hey, You,
  Get Off of My Cloud: Exploring
  Information Leakage in Third-Party
  Compute Clouds.” In CCS, 2009.

               Distributed System Lab.   19
Thank you!

             Distributed System Lab.   20

Shared By: