Pandavirtualization: Exploiting the Xen hypervisor

Pandavirtualization: Exploiting the Xen hypervisor
Posted by Jann Horn, Project Zero

On 2017-03-14, I reported a bug to Xen’s security team that permits an attacker with control over the kernel of a paravirtualized x86-64 Xen guest to break out of the hypervisor and gain full control over the machine’s physical memory. The Xen Project publicly released an advisory and a patch for this issue 2017-04-04. To demonstrate the impact of the issue, I created an exploit that, when executed in one 64-bit PV guest with root privileges, will execute a shell command as root in all other 64-bit PV guests (including dom0) on the same physical machine.[…]







guestrace: VM guess whole-system-call tracer

guestrace: A whole-system system-call tracer for VM guests
Ryan Johnson began writing guestrace as a prototype for a research project. Since then, we have packaged guestrace as a stand-alone utility. A properly-configured guestrace will print as they occur the system calls which processes invoke within a guest host. The guestrace utility relies on libvmi to perform virtual-machine introspection. Guestrace also provides a library, libguestrace, which gives programmers access to the guestrace engine. This is useful for programs which must trace system calls and do more than merely print them. […]



new CHIPSEC test for Xen XSA-188

Proof-of-concept module for Xen XSA-188 (https://xenbits.xen.org/xsa/advisory-188.html)
CVE-2016-7154: “use after free in FIFO event channel code”
Discovered by Mikhail Gorobets
This module triggers host crash on vulnerable Xen 4.4
“chipsec_main.py -m tools.vmm.xen.xsa188“




“Xenpwn is a toolkit for memory access tracing using hardware assisted virtualization. It runs as a normal user space application inside the management domain (dom0) of a Xen hypervisor and can be used to trace any memory accesses performed by another VM running on the same hypervisor. The toolkit uses libvmi for interaction with the Xen hypervisor API and relies on simutrace for efficient storage of memory traces. Xenpwn was used to discover double fetch vulnerabilities in the inter domain communication of the Xen hypervisor resulting in XSA 155. Further research on identifying double fetches in other software is still ongoing.[…]”



CHIPSEC updates

The CHIPSEC team have tweeted about an upcoming 1.2.3 release with more Xen, Hyper-V, IOMMU, EPT support.

Also, Yuriy Bulygin of the Intel CHIPSEC team has posted some videos of their REcon training showing CHIPSEC usage:

It looks like their last checkin to the public git repo was in April:


Description of Xen exploit XSA-105

Jérémie Boutoille has a new blog post with information on Xen, with a video at the beginning for those who are too busy to read the entire article:

Xen exploitation part 1: XSA-105, from nobody to root

This blog post describes the exploitation of Xen Security Advisory 105 (XSA-105)  (CVE-2014-7155). This post explains the environment setup and shows the development of a fully working exploit on Linux 4.4.5. We are not aware of any public exploit for this vulnerability, although Andrei Lutas wrote excellent articles  describing the root cause of the vulnerability and how to trigger it. This post explains the environment setup and shows the development of a fully working exploit on Linux 4.4.5 (it probably works with many others versions). […]



Xen patches for AMD FIP/FCS/FDP/FDS/FOP instruction leak

The Xen security team posted an updated security advisory with a workaround to an AMD CPU issue. Heavily-edited announcement follows, see the OSS-security list post for the full announcement and patches:

Xen Security Advisory CVE-2016-3158,CVE-2016-3159 / XSA-172
version 3
broken AMD FPU FIP/FDP/FOP leak workaround

There is a workaround in Xen to deal with the fact that AMD CPUs don’t load the x86 registers FIP (and possibly FCS), FDP (and possibly FDS), and FOP from memory (via XRSTOR or FXRSTOR) when there is no pending unmasked exception.  (See XSA-52.) However, this workaround does not cover all possible input cases. This is because writes to the hardware FSW.ES bit, which the current workaround is based on, are ignored; instead, the CPU calculates FSW.ES from the pending exception and exception mask bits.  Xen therefore needs to do the same. Note that part of said workaround was the subject of XSA-52. This can leak register contents from one guest to another.  The registers in question are the FPU instruction and data pointers and opcode.

A malicious domain is able to obtain address space usage and timing information, about another domain, at a fairly low rate. The leaked address information might be used to help defeat address space randomisation in order to enable another attack.  The leaked address and timing information forms a low-bandwidth covert channel which might be used to gain information about the operation of a target guest. The affected FPU facility would not normally be used by cryptographic operations, as it does not provide cryptographically-relevant SIMD functions. It appears to us very unlikely that the leak might directly compromise sensitive information such as cryptographic keys, although (without knowledge of the guest software) this cannot be ruled out.  (This is notwithstanding the contrary statement in `Impact’ in XSA-52.)

Xen versions 4.0 and onwards are vulnerable.  Any kind of guest can exploit the vulnerability. The vulnerability is exposed only on AMD x86 systems.  Intel and ARM systems do not expose this vulnerability. Both PV and HVM guests are affected. The vulnerability can be avoided if the guest kernel is controlled by the host rather than guest administrator, provided that further steps are taken to prevent the guest administrator from loading code into the kernel (e.g. by disabling loadable modules etc) or from using other mechanisms which allow them to run code at kernel privilege. On Xen versions 4.3 and earlier, turning off XSAVE support via the “no-xsave” hypervisor command line option will avoid the vulnerability. On Xen versions 4.4 and onwards there is no other known mitigation.

This issue was discovered by Jan Beulich from SUSE.