What it is
Co-residence threats in Cloud
In current commercial cloud, cloud providers allow multiple users to share the physical machine rather than assigning a dedicated machine to every user. Although in theory, VMs running on the same server (i.e., ci-resident VMs) should be logically isolated from each other, malicious users can still circumvent the logical isolation, and obtain sensitive information from co-resident VMs [6].
A malicious virtual machine (VM) can extract fine-grained information from a victim VM running on the same physical machine.
Thus malicious users can try to co-locate their VMs with target VMs on the same physical server, and then exploit side channels to extract private information from the victim [5].
Types
- Access Driven
- The attackers program monitors usage of a shared architectural component to learn information about the key, e.g., the data cache, instruction cache, floating-point multiplier, or branch-prediction cache.
- The attackers could be asynchronous, meaning that they do not require the attacker to achieve precisely timed observations of the victim by actively triggering the victim operation.
Examples
- Zhang et al. [1] demonstrate a VM can extract a private ElGamal decryption key from a co-resident victim VM running Gnu Privacy Guard (GnuPG), which is a popular software package that implements the OpenPGP email encryption standard.
- By overloading the CPU while a victim AES encryption process is running. They managed to gain control over the CPU and suspend the AES process thereby gaining an opportunity to monitor cache access of the victim process.
How it works
The first step for the attackers is to try to achieve co-residence with the target VMs, and then conduct covert channel attacks by exploiting shared microarchitectural components such as caches.
How to achieve co-residence
- The most straightforward approach is to use a brute-force strategy, start as many VMs as possible until co-residence is achieved.
- [7][8] investigate how to efficiency achieve co-residency.
Approach 1: PRIME + PROBE method
- Step 1:
- Attackers create one or more eviction sets. An eviction set is a sequence of memory addresses that are all mapped by the CPU into the same cache set.
- The PRIME+PROBE method also assumes that the victim code uses this cache set for its own code or data.
- Step 2:
- The attackers prime the cache set by accessing the eviction set in an appropriate way.
- This force the eviction of the victim’s data or instructions from the cache set and brings it to a known state.
- Step 3:
- The attackers trigger the victim process, or passively waits for it to execute.
- During this execution step, the victim may potentially utilize the cashe and evict some of the attacker’s elements from the cache set.
- Step 4:
- The attacker probes the cache set by accessing the eviction set again.
- A probe step with a low access latency suggests that the attacker’s eviction set is still in the cache.
- Conversely, a higher access latency suggests that the victim’s code made use of the cashe set and evicted some of the attacker’s memory elements.
- The attackers thus learns about the victim’s internal state.
- The actual timing measurement is carried out by using the (unpriviledged) instruction rdtsc, which provides a hide-fidelity measurement of the CPU cycle count.
- Iterating over the eviction set in the probing phase forces the cache set yet again into an attacker-controlled state, thus preparing for the next round of measurement.
How to defense against it
Several countermeasures have been proposed at different levels: hypervisor, guest OS, hardware and application-layer approaches.
1. Eliminating the side channels
- Hypervisor-based approach.
- Modify the Xen scheduler to limit the frequency in which an attacker can preempt the victim.
- Locking cache lines to prevent preemption by an attacker and multiplexing the cache lines among VMs such that each has an access to its own.
- Remove high resolution clock
- Note the side-channels attacks relies on it
- Add noise/latency
- Periodic time-shared cache cleasing, in order to make the side channel noisy.
- Hide the program execution time
- Alter the timing exposed to an external observer.
- Statistical multiplexing of shared resources to prevent eavesdropping.
- Guest OS
- Injecting noise into protected processes on L1 and L2 caches.
- Hardware
- Hardware design incorporates access randomization and resource partitioning.
- e.g., avoid sharing of sensitive resources
- Remove hypervisor, and use hardware mechanisms for the isolation of access to shared resources
Cons
- These methods often require substantial changes to be made to existing cloud platforms, and hence are unlikely to be adopted by cloud providers any time soon.
2. Increasing the difficulty of verifying co-residence
- Existing works show that traceroute tool can be used to decide the IP address of a VM’s Dom0, which is a privileged VM that manages all VMs on a host. If two Dom0 IP addresses are the same, then the corresponding VMs are co-resident.
- Cloud provider can prevent Dom0’s IP address from being exposed to customers. so that attackers will be forced to resort to other options that do not rely no network measurements.
- However, as more and more methods of detecting co-residence have been proposed [10-12], simply hiding Dom0’s IP address is not sufficient. [9]
3. Increasing the difficulty of steal information
- Application-level
- Partitioning a cryptographic key across multiple VMs.
- E.g, divide the secrets using Shamir’s secret
4. Detecting the features of co-resident attacks
- When attackers use Prime+Probe technique to extract information from the victim, there are abnormalities in the CPU and RAM utilization, system calls, and cache miss behaviors. [13][14]
5. Migrating VMs periodically
- VM migration
- This approach is proposed in [4].
- Pros
- Other approaches are not suitable for immediate deployment due to the required modification to the cloud platforms, while VM migrations can be implemented immediately.
6. Using VM allocation policies to make it difficult to achieve co-residence
References
[1] Cross-VM side channels and their use to extract private keys, CCS 2012
[2] Wait a Minute! A fast, Cross-VM Attack on AES, in Research in Attacks, Intrusions and Defenses, LCNS 2-14
[3] The Spy in the Sandbox: Practical Cache Attacks in JavaScript and their Implications, CCS15
[4] Nomad: Mitigating Arbitrary Cloud Side Channels via Provider-Assisted Migration, CCS15
[5] Security Games for Virtual Machine Allocation in Cloud Computing, by Yi Han et al., in GameSec15
[6] Hey, You, Get Off of My Cloud: Exploring Information Leakage in Third-Party Compute Clouds, by Restenpart, T. et al., in CCS09
[7] A Placement Vulnerability Study in Multi-Tenant Public Clouds, by Venkatanathan Varadarajan, in UnixSecurity15
[8] A Measurement Study on Co-residence Threat inside the Cloud, by Haining Wang, in UnixSecurity
[9] Using Virtual Machine Allocation Policies to Defend against Co-resident Attacks in Cloud Computing, by Yi Han et al, in Transactions on Dependable and Secure Computing
[10] Detecting co-residency with Active Traffic Analysis Techniques, by A. Bates, in CCSW12
[11] Detecting VMs co-residency in Cloud: Using Cached-based Side Channels Attacks, by S. Yu 2013
[12] On Detecting Co-resident Cloud Instances Using Network Flow Watermarking Techniques, by A. Bates, in International Journal of Information Security, 2014
[13] Detecting malicious Coresident Virtual Machines Indulging in Load-Based Attacks, by S. Sundareswaran, in Information and Communication Security 2013
[14] An Approach with Two-stage Mode to Detect Cache-based Side Channel Attacks, by S. Yu, in ICOIN 2013
