|
http://theinvisiblethings.blogspot.com/search/label/xen%20hacking
Saturday, September 06, 2008Xen 0wning Trilogy: code, demos and q35 attack details posted 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. Labels: hypervisor rootkits, virtualization based rootkits, xen hacking, xen heap exploiting Wednesday, August 20, 2008Attacking Xen: DomU vs. Dom0 consideration As
it usually happens, there is some confusion regarding the attacks
presented in our Xen 0wning Trilogy. Some people think they are
possible only from Dom0 (the Xen's privileged, administrative domain)
while some other people have the impression that all the attacks are
possible from any unprivileged domain (DomU in Xen’s terminology). The
truth is in the middle though.
Most of the attacks we presented do indeed require that the attacker first obtained access to Dom0 and only from there can launch further attacks. For example the DMA attacks that allow to overwrite hypervisor memory do indeed assume Dom0 access. The same applies to the Q35 exploit - this one is similar to the above mentioned DMA attacks in that it also requires access to certain hardware (that is possible from Dom0), but has an advantage that can bypass the hypervisor VT-d protection in the recent Xen 3.3. There are several reasons why those attacks are still very important though: 1) First note, that the requirement for the attacker to have access to Dom0 in order to install e.g. hypervisor rootkits, is similar to the requirement that in order to install a Windows or Linux rootkit, one first needs to obtain administrator's privileges. Yet we know that Windows or Linux rootkits is a serious security problem. 2) Concerning the Xen-based systems specifically: over the last year several bugs have been discovered and published, that allowed an attacker to gain control of the Domain0 from an unprivileged domain (i.e. escape from the virtual machine). Rafal has discovered one such bug in December 2007. 3) Recent versions of Xen make deliberate effort to protect the hypervisor even from the Dom0. On systems that have IOMMU support (e.g. Intel's VT-d), the hypervisor memory is protected from tampering using both the processor's ring3/ring0 separation mechanism as well as the IOMMU protection. We showed that those protections can be bypassed. The attempt to isolate hypervisor and protect it even from attacks originating from Dom0 is not surprising. After all if we would like to treat the hypervisor as a root of trust, then we should make sure that its code base is minimal. If we now allow Dom0 to effectively be the hypervisor (i.e. if we don't care about Dom0-to-hypervisor escalations) then we should include all the Dom0 code to the hypervisor code base, when evaluating hypervisor security. This would result in our "extended hypervisor" having not ~300k lines of code (like current Xen does), but millions of lines of code! Having said that all about how important it is to prevent all the possible Dom0-to-hypervisor attacks, I should stress that we also presented an attack that does not require Dom0 access and that can be spawned from an unprivileged DomU domain. As far as I'm aware, Rafal's FLASK bug & exploit (presented in the 2nd presentation) was the first public example of a successful exploitation of an overflow in a bare-metal hypervisor. The bug was a heap overflow and Rafal presented some clever tricks of how to control the Xen's heap allocations in order to make this bug exploitable. Please note that all the rootkit-like stuff that we also presented, i.e. Rafal's Xen Loadable Modules framework and his hypervisor rootkits, as well as Alex's and mine XenBluePill, can all be used with all the above mentioned attacks. So, e.g. if we are on a machine that has VT-d support and run Xen 3.3 we can still use the Q35 attack and get the XLM framework running and then use it to install e.g. XenBluePill on top of running Xen, as showed during the 3rd presentation. Similarly, we could use the FLASK exploit and get XLM running again and again used it for installation of the other stuff. Hope this clears some confusion about our presentations. As already promised, the codes and demos and full version of the 2nd talk slides (with the Q35 attack details) will be posted after Intel release the patch for their motherboards. Stay tuned. Labels: xen hacking Friday, August 08, 2008Our 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. Labels: hypervisor rootkits, virtualization based rootkits, xen hacking, xen heap exploiting Monday, July 07, 20080wning 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. Labels: hypervisor rootkits, virtualization based rootkits, xen hacking |
