Our Xen 0wning Trilogy Highlights

Below you can find highlights of the three presentations, collectively referred to as "Xen 0wning Trilogy", that Alex, Rafal and I gave today at the Black Hat conference in Las Vegas.

Talk #1

1) Practical implementation of reliable and portable DMA attacks from Domain 0 to the Xen hypervisor memory.

2) Xen Loadable Modules :) A framework that allows to load arbitrary C code modules into the running Xen hypervisor. It uses DMA attack from the previous point to get access to Xen memory.

3) Two implementations of Xen Hypervisor Rootkits. This was the first time that working hypervisor rootkits have been presented (note the distinction between hypervisor rootkit vs. virtualization based rootkits).

Talk #2

1) Discussed how Xen 3.3 makes use of the Intel VT-d technology to protect the hypervisor.

2) Then we discussed how to bypass such VT-d protection on certain motherboards, like e.g. Intel DQ35 board.

3) An extra bonus: our attack from the previous point allows also to subvert the SMM handler and e.g. install an SMM rootkit in the system.

4) Discussed other Xen security mechanisms like driver domains, stub domains, PV GRUB and also attempted to quickly compare the state of Xen security design with the Hyper-V and ESX hypervisor.

5) Showed an exploitable heap overflow bug in the Xen hypervisor. The bug was in the FLASK module -- the NSA implementation of Xen Security Modules. FLASK, however, is not turned on by default, so even though we showed how to successfully exploit this heap overflow (which results in an escape from an unprivileged domain directly to the hypervisor), this is not a bug that can be used to 0wn The Planet. It shows, however, what happens when people start adding more and more code into the hypervisor.

6) Introduced HyperGuard -- a project done in cooperation with Phoenix Technologies. HyperGuard is going to be a SMM-based integrity scanner for Xen-like hypervisors. With HyperGuard we take a different approach then other integrity scanners do -- rather than ensuring the correctness of the code and data of the hypervisor, which might be very tricky, we instead ensure there is no untrusted code in the hypervisor, which is a much simpler task.

Talk #3

1) Provided detailed description of how to implement nested hardware based virtualization on AMD-V and VT-x (a copy of the slides from my RSA speech in April).

2) Showed how to use this nested virtualization to implement Blue Pill Boot, that can be used to virtualize the system right from the boot stage. We mentioned the best defend against this kind of system compromises is a trusted boot mechanism, either SRTM or DRTM, as implemented e.g. by Xen's tboot.

3) Consequently we showed Xen Blue Pill that is able to move a running Xen system into a virtual machine on the fly. This, on the other hand, cannot be prevented by neither the SRTM nor DRTM technology. XBP is a good example that running a legitimate hypervisor doesn't always prevent bluepill-like malware from being installed in the system.

4) Finally, discussed the XBP detection. First, we noted that all the "VMM detectors", proposed over the last years, that try to detect if there is a hypervisor running above, are useless in the case of a bluepilled Xen system. The only one approach that could be used is the direct timing analysis of the #VMEXIT times in order to distinguish between the native Xen case vs. bluepilled Xen case. We noted however, that direct timing analysis will not observe any differences when run from PV domains on AMD processors, and that it will observe little difference when run from HVM domains (7k vs. 5k cycles). The detection is easier on Intel processors, because of the unconditional #VMEXIT that we cannot get rid of.

All the three talks can be found here.