lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 05 Aug 2015 23:47:46 +0200
From: antonio <antonio@...resi.net>
To: fulldisclosure@...lists.org
Subject: [FD] Security Advisory - "Cross-VM ASL INtrospection (CAIN)"

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there

We discovered a new 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 details are described in the security advisory below and in our
WOOT'15 paper:
https://www.usenix.org/conference/woot15/workshop-program/presentation/barresi

Several vendors were notified about this issue in the beginning of
June. This issue has CVE-2015-2877 assigned.

An overview can also be found here:
http://www.antoniobarresi.com/security/cloud/2015/07/30/cain/

Best,
Antonio


Security Advisory - "Cross-VM ASL INtrospection (CAIN)"
- -------------------------------------------------------

Date: July 30, 2015


Description
- -----------
We discovered a new 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 [1, 2]. VMMs that perform
memory deduplication enable malicious VMs to detect shared pages as
deduplicated pages usually incur higher write times because of the
required copy-on-write.

Our attack relies on a combination of the available side-channel, the
ASLR implementation characteristics and the existence of suitable pages
with certain properties (see below).

We found memory pages in Windows and Linux systems that allow a
malicious VM to silently brute force all possible base addresses.
These pages are mostly static, long-lived and their entropy is directly
derived from the randomized base address of a library or executable,
making it possible to probe for the right randomized base address.

Our PoC attack against the default configuration of KVM breaks ASLR of a
neighboring Windows Server 2012 (x86_64) VM in less than 5 hours. We
estimate an attack against Linux based systems (x86_64) to take around
18 days (with the same configuration).

We expect a more determined attacker to further reduce attack time. The
attack time also depends on the memory available to an attacker (more
memory reduces attack time).

Note: the attacker only needs user rights within the attacking VM thus
no root/Administrator/elevated privileges are required.


Attack variants
- ---------------
It is important to note that although the availability of the mentioned
pages is existential for the attack, different data or code pages might
be suitable for CAIN-like attacks. We cannot exclude that other pages
(data or code) might be used by attackers to leak randomized base
addresses. Therefore all mitigations that aim at specific pages are only
effective as long as no other pages are available to be misused by
attackers.


Impact
- ------
A malicious attacker can reliably leak the randomized base addresses of
libraries and the executable of a process within a neighboring VM thus
completely bypassing ASLR.


Affected VMMs (Side-channel)
- ----------------------------
Verified: KVM (on 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 sharing, see also [3])


Affected Operating Systems (Victims)
- ------------------------------------
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


Mitigation
- ----------
- - Deactivation of memory deduplication.

- - Improvement of ASLR in victim systems by increasing entropy.

- - Increase of entropy in memory pages of processes that are mainly
  static, long-lived and that contain base addresses (or can be directly
  derived by them).

- - Increase size of shared pages i.e., use large pages for deduplication
  (e.g., 2MB). Reducing entropy with larger pages takes much longer due
  to the increase in the memory requirements of the attacker.

- - VMMs can try to detect if an attack is going on based on memory
  allocation and page fault characteristics. This requires further
  investigation.


Information related to Windows systems
- --------------------------------------
Windows operating systems seem to be the most feasible targets. Even
under High-Entropy ASLR, entropy for DLL base addresses is 19-bits. This
number of bits and everything below can reliably be brute forced through
the memory deduplication side-channel.

The pages that make the attack possible are the first PE file pages
mapped into the virtual address space of a process. These pages are
static except for the ImageBase field within the Optional Header. The
ImageBase field will be updated with the run-time base address of the
DLL. Attackers can use this page to reliably brute force the ImageBase
field to recover the randomized run-time base addresses of specific
DLLs. As Windows employs system-wide ASLR the recovered base addresses
can be used in attacks against all processes.

Mitigations:
- - Increase of ASLR entropy for code pages (DLLs and executables)
- - Increase of entropy within the first page of a mapped PE file
  (to mitigate the PoC attack vector)
- - Elimination of all suitable pages


Information related to Linux systems
- ------------------------------------
Linux based operating systems usually make use of the GNU tool chain. In
GNU based systems, ELF shared libraries are usually deployed as PIC
(Position-Independent Code). Thus most code pages have the same content
despite their randomized base address. However, some pages still exist
that are mapped from the ELF file's disk image to memory that contain
base address relocations (R_X86_64_RELATIVE). These pages can be used by
attackers to brute force the base address of a shared library in memory
(e.g, libc). We found pages within the GNU_RELRO segment to be suitable.
An attack against Linux based x86_64 systems can take around 18 days
(estimate) with 4GB of attacker memory when running on a default KVM
VMM. With 8GB attacker memory we estimate an attack time of 8.7 days.
Attacks against x86 32-bit systems take considerably less (around hours).
As Linux employs process-wide ASLR the recovered base addresses still
need to be linked to a specific process within a victim VM.

Mitigation:
- - Increase entropy within GNU_RELRO pages
- - Elimination of all suitable pages


Information related to KVM
- --------------------------
We implemented a PoC against KVM that is able to reliably recover the
ntdll.dll randomized base address of a x86_64 Windows Sever 2012 victim
VM. The attack takes less than 5 hours with the default KVM
configuration of a Ubuntu Server 14.04.2 (sleep_millisecs = 200).
Increasing sleep_millisecs slows down the attack, but does not prevent
it. The attack also works when multiple victim VMs are running on the
same KVM (we tested it with up to 6 victim VMs). While increasing the
number of running VMs, attack time increases as well.

As the attack is made possible as a combination of the side-channel and
of victim VM characteristics, mitigations can be implemented on the VMM
or victim VM side.

For VMMs we see 2 possible remedies:
- - Deactivation of memory deduplication.
- - Detection of ongoing attacks based on memory allocation and page
  fault characteristics. This needs to be further investigated.

Slowing down detection and merging of same-content pages might also be
partly effective as attack time will inevitably increase.


Disvovered by:
- --------------
Antonio Barresi, Kaveh Razavi, Mathias Payer, Thomas R. Gross


References:
- -----------
[1]: "Memory Deduplication as a Threat to the Guest OS"
https://staff.aist.go.jp/c.artho/papers/EuroSec2011-suzaki.pdf

[2]: "Security Implications of Memory Deduplication in a Virtualized
Environment" http://www.cs.wm.edu/~hnw/paper/memdedup.pdf

[3]: "Mastering Hyper-V 2012 R2 with System Center and Windows Azure"
Section "Memory Resources", "Why Page Sharing Technologies Are Not Used
with Hyper-V"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVwoR6AAoJEIm5W8tenpzo5SAQAL8oo6wtQirwgFZQUGr+qu02
BafIYY20glwuc+9enuwNxyLaQU9M3kHxUDzfgvXRMnwZ+6Lrucn5ABRM0HaO5y9Z
WhF4tbq/bfimo2qSUnCu1hj0Nx5OGzmIbfl+TigilitlD+kvnArYm4ZX8Qy5MpKi
naythhRAA0Juw+zlIg5TgeyT0dhnuWMMYrxOI9ZmVTf7832q3i9LPEnT3rzSFpP0
C+Y9gQM3VJWithnt4Ef2fK2a62M9cSF4/YBzO+A1QRAYK94dufRBdUJUZUulud/e
RpHs95+2BamKz3XqZElRWDsPQ/X4kr2xGpbe7t0SZ5hEmzQecrlrIFJUhKQ20mPw
OIb9gN++3Ea5JVIR9yi0yjnye2TwPaDGHDowszEO+YQpFabNDP6O5NgY5/XL+zoO
jmb2qDi2c6mmbuZTAopySryk5qUuyQDKHV/c9v2fJ2XMD6c9t6OWkJpf+65VPYCh
nSDULNixX+hO+R8cDku/UpyWg/bfI6Esz2JKYRu1Y7rF+L5WZ0BPcfC/uZ/7AiAh
Qs46eCRa63vcr3cwicKqIP0kHChb8QX1/DF0GkrVIk5p2/aO3GVwH+RPQ8wGYv4M
4WDmm0uLkmpvX+HmDWjhr4lu6C8Up+Z1FhUygq7a4DdrD0OF+tQhKAd96XCuvorx
j8Au/ZwIjSkarPpuU2hM
=+P1i
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ