Attacking 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.