We have posted all the code that we used last month during our Black Hat presentations about Xen security, and you can get it here. This includes the full source code for:
1) The generic Xen Loadable Modules framework
2) Implementation of the two Xen Hypervisor Rootkits
3) The Q35 exploit
4) The FLASK heap overflow exploit
5) The BluePillBoot (with nested virtualization support on SVM)
6) The XenBluePill (with nested virtualization support on SVM)
Beware the code is by far not user-friendly, it requires advanced Linux/Xen, C and system-level programming skills in order to tweak some constants and run it successfully on your system. Do not send us questions how to compile/run it, as we don’t have time to answer such questions. Also do not send questions how the code works – if you can’t figure it out by reading our slides and the source code, then it means you should probably spend more time on this yourself. On the other hand, we would appreciate any constructive feedback.
The code is our gift to the research community. There is no warranty and Invisible Things Lab takes no responsibility for any potential damage that this code might cause (e.g. by rebooting your machine) or any potential malicious usage of this code, or any other code built on top of this code. We believe that by publishing this code we help to create more secure systems in the future.
Additionally, we also posted the full version of our second Black Hat talk, which now includes all the slides about the Q35 bug and how we exploited it. Those slides had to be previously removed during our Black Hat presentation, as the patch was still unavailable during that time.
Showing posts with label hypervisor rootkits. Show all posts
Showing posts with label hypervisor rootkits. Show all posts
Saturday, September 06, 2008
Friday, August 08, 2008
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.
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.
Monday, July 07, 2008
0wning Xen in Vegas!
At this year’s Black Hat conference in Las Vegas in August we will be presenting three talks about the Xen hypervisor (in)security. The three presentations have been designed in such a way that they complement each other and create one bigger entirety, thus they can be referred as “Xen 0wning Trilogy” for brevity.In the first presentation, Subverting the Xen hypervisor, Rafal will discuss how to modify the Xen’s hypervisor memory and consequently how to use this ability to plant hypervisor rootkits inside Xen (everything on the fly, without rebooting Xen). Hypervisor rootkits are very different creatures from virtualization based rootkits (e.g. Bluepill). This will be the first public demonstration of practical VMM 0wning (proof of concept code will be released, of course).
In the second talk, Detecting and Preventing the Xen hypervisor subversions, Rafal and I will discuss various anti-subverting techniques (IOMMU, Xen’s driver- and stub- domains) and whether they really can protect the Xen (or similar) hypervisor from compromises. After demonstrating that those mechanisms can be bypassed, we will switch to discussing hypervisor integrity scanning and will present some prototype solutions to this problem.
Our trilogy wouldn’t be complete without discussing virtualization based malware in the context of bare-metal hypervisor compromises. Thus, in the third speech, Bluepilling the Xen hypervisor, Alex and I will discuss how to insert Bluepill on top of the running Xen hypervisor. We will show how to do that both with and without restart (i.e. on the fly). To make this possible, our Bluepill needs to support full nested virtualization, so that Xen can still function properly. We will also discuss how the “Bluepill detection” methods proposed over the last 2 years, as well as the integrity scanning methods discussed in the previous speech, fit into this new scenario and how far we are from the stealth malware’s Holy Grail ;)
Special thanks to Black Hat organizers for scheduling all the three presentations one after another in a dedicated Virtualization track on the 2nd day of the conference (August 7th).
It’s worth noting that we chose Xen as the target not because we think it’s insecure and worthless. On the contrary, we believe Xen is the most secure bare-metal hypervisor out there (especially with all the goodies in the upcoming Xen 3.3). Still we believe that it needs some improvements when it comes to security. We hope that our presentations will help making Xen (and similar hypervisors) more secure.
Subscribe to:
Posts (Atom)
