We found an attack vector against memory deduplication in Virtual Machine Monitors (VMM) where attackers can effectively leak randomized base addresses of libraries and executables in processes of neighboring Virtual Machines (VM). The attack takes advantage of the well known memory deduplication side-channel.

The details of the attack are described in our WOOT'15 paper and in the security advisory. I decided to write a blog post to briefly cover the most important points and to address the impact of this issue.

The CAIN attack allows an attacker with user privileges to infer the address-space layout of processes running on co-located VMs. This works if the VMM uses page based same content memory deduplication. The attack takes advantage of the well known memory deduplication side-channel (see also here and here). Shared pages incur higher write times because of their copy-on-write property. Attackers can use this to detect if a page is shared between VMs. By crafting specific pages an attacker can therefore guess if a page exists within co-located VMs. As multiple guesses are possible (limited by attacker available memory) this allows to brute-force page content to some extent (i.e., a certain range of values).

By taking advantage of this side-channel an attacker can infer the randomized base addresses of executables and libraries by crafting pages that contain the base address or some base address derived values. With one page per guess the attacker can then try to find a shared page thus revealing a randomized base address in one of the co-located VMs. Pages suitable to brute-force base addresses have certain properties. They are mostly static, unique for a specific library or executable, have a predictable allignment and they contain the randomized base address in some form.

We found such pages in Windows and Linux systems thereby allowing to attack these systems. The attack works better against Windows systems because of the limited ASLR entropy for executables and DLLs. Moreover ASLR on Windows is done system-wide at boot-time. The attack should also work on Linux but requires more memory or more time. Furthermore linking the base addresses to specific systems or processes becomes more tricky when targeting Linux systems.

More details can be found in our WOOT'15 paper and in the security advisory.

Which VMMs are affected?

We verified the issue on KVM (Ubuntu Server 14.04.2 with Linux Kernel 3.16.1).

Most probably also affected:
- All KVM versions with KSM (Kernel Same-Page Merging)
- VMware products with TPS (Transparent Page Sharing) enabled (NOT enabled by default)
- VirtualBox supporting Page Fusion
- Any other VMM that uses page based same content memory deduplication

Not affected:
- Microsoft Hyper-V products (does not perform page based memory deduplication)

Which systems can be attacked?

Verified: Windows Sever 2012 Datacenter (6.2.9200 Build 9200)
Existence of suitable pages also verified on: Ubuntu Linux 14.04 x86_64

Most probably also affected:
- Most 64-bit and 32-bit x86 Windows operating systems
- Most 64-bit and 32-bit x86 GNU/Linux distributions
- Other operating systems like OpenBSD, FreeBSD, etc. as well

What is the impact?

An attacker with user privileges can leak the randomized base addresses of code regions (libraries and executables) of processes running in co-located VMs. This allows to bypass ASLR by constructing a code-reuse attack with code locations now known to the attacker.

Do you have a PoC exploit?

Yes, we implemented the attack and evaluated it on a Ubuntu Server 14.04.2 setup with KVM.

How long does the attack take?

In our evaluation we targeted the ntdll.dll of a Windows Sever 2012 Datacenter (6.2.9200 Build 9200) system. This took around 5 hours with the default KVM configuration of sleep_millisecs = 200. Attacking Linux systems will take longer (several days).

Are real-world cloud providers affected?

Commercial cloud providers indeed use memory deduplication. Some do disable it or they use a VMM that does not support it at all. Unfortunately it's usually not apparent if a cloud provider uses memory deduplication or not as this information is not publicly disclosed.

How can the issue be mitigated?

Currently it seems that disabling memory deduplication is the only real mitigation. Further possible mitigations are described in the security advisory.

Is there a CVE-ID for this issue?

Yes, CVE-2015-2877.