Uncategorized

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. […]

https://www.flyn.org/projects/guestrace/index.html

Standard
Uncategorized

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
Usage:
“chipsec_main.py -m tools.vmm.xen.xsa188“

https://github.com/chipsec/chipsec/blob/master/source/tool/chipsec/modules/tools/vmm/xen/xsa188.py

Standard
Uncategorized

Xenpwn

“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.[…]”

https://github.com/felixwilhelm/xenpwn

Standard
Uncategorized

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:

https://github.com/chipsec/chipsec
It looks like their last checkin to the public git repo was in April:
https://github.com/chipsec/chipsec/commits/master

Standard
Uncategorized

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). […]

http://blog.quarkslab.com/xen-exploitation-part-1-xsa-105-from-nobody-to-root.html

Standard
Uncategorized

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.

http://xenbits.xen.org/xsa/advisory-172.html
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2016-3159
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3158

 

Standard
Uncategorized

Critical bug in Xen hypervisor

Wow, Joanna of ITL says “IMHO this is the worst bug affecting Xen, ever.”

Excerpt from Qubes Security Bulletin #22:

Critical Xen bug in PV memory virtualization code (XSA 148)

The Xen Security Team has announced a critical security bug (XSA 148) in the hypervisor code handling memory virtualization for the PV VMs [1]:

| The code to validate level 2 page table entries is bypassed when
| certain conditions are satisfied.  This means that a PV guest can
| create writeable mappings using super page mappings.
|
| Such writeable mappings can violate Xen intended invariants for pages
| which Xen is supposed to keep read-only.

The above is a political way of stating the bug is a very critical one. Probably the worst we have seen affecting the Xen hypervisor, ever. Sadly.
[…]

Full advisory:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-022-2015.txt

Standard