As stated in the mmap manual, MAP_POPULATE will populate the mapping in page tables without waiting for a page fault to occur before updating the page table. Under the kernel module context, accessing the mapped page without this option leads to a failure.

By mmap()ing the address 0x7FFFFFFFF000, the kernel will allocate a page (0x1000 bytes) starting at address 0x7FFFFFFFF000. Since the page has a size of 0x1000 bytes, the allocated address range will be from 0x7FFFFFFFF000 to 0x7FFFFFFFFFFF.

Since the SYSCALL opcode (0F 05) is 2 bytes, having this instruction located at 0x7FFFFFFFFFFE triggers the bug:

After calling the SYSCALL instruction, the return address will be 0x800000000000 which is non-canonical, eventually triggering the #GP with ring0 privileges and attacker-controlled registers when executing the SYSRET instruction.


3. Advanced Exploitation on Xen and Citrix XenServer

Exploitation has been achieved under a 64-bit Linux PV guest running on Citrix XenServer 6.0.0 with Xen version 4.1.1. The method will work on other versions as well.

3.1 - Rewriting the trap frame return address

Since the guest is not fully virtualized, using the "sidt" instruction actually returns the address of the Xen IDT. So smashing the Xen IDT allows arbitrary code execution. While the exploitation is local, it is comparable to a remote exploitation in the way that one does not know how to repair the IDT after achieving code execution. Even by using preserved IDT entries such as Divide Error, and scanning forward in order to reconstruct the IDT, in a lot of cases, more than the IDT was mangled and revealed close to impossible to reconstruct. Thus, this technique works perfectly on some Xen versions but may fail on others.

A more reliable method is thus needed in order to exploit this vulnerability without knowing the Xen address space.

I had the opportunity to talk to Rafal Wojtczuk (who discovered this vulnerability) after his BlackHat presentation about this flaw. He actually came up with a clever idea which does not rely on any hardcoded address but requires digging a little in the internals of Xen exception handling.

The exploitation method relies on the way Xen retrieves the "current" variable, which is a pointer to a vCPU (Virtual CPU) structure which holds information about the virtual machine state: general purpose registers, virtual IDT, page tables, etc.

Xen retrieves the current_vcpu pointer by using the address of the bottom of the stack, thanks to the "get_current()" macro:

When dispatching the #GP exception, the following code is reached in "arch/x86/x86-64/entry.S":

When entering the "do_general_protection()" function in "arch/x86/traps.c", several checks are performed:

Under normal circumstances, the #GP handler gracefully fails with a kernel panic, which is not the desired behavior. However the guest_mode macro can be tricked into thinking the #GP is actually triggered from ring3:

The "guest_cpu_user_regs()" macro is defined as follows in "xen/include/asm-x86/current.h":

If one can make the diff variable having a NULL value, the check will pass and the exception will be treated as being issued from ring3, another path to be followed.

The GET_CURRENT and "guest_cpu_user_regs()" respectively give the following assembly:

Setting these two values is easily achievable, since one can set RSP to a user-controlled address and filled with controlled values.

The exception is considered to be coming from ring3 and thus the following code path is executed:

Eventually the "emulate_privileged_op()" is called in "xen/x86/traps.c", but will generate a #PF in the "read_descriptor()" sub function on the following piece of code:

The "__get_user()" macro actually uses the current segment selector as the index in the kernel virtual GDT / IDT which causes a #PF on an invalid read.

The "do_page_fault()" exception handler is then reached in "xen/x86/traps.c":

Since the RSP address has been modified due to arguments pushed on the stack by the nested exception, the guest_mode check is no longer valid and thus calls the "spurious_page_fault()" function:

The "in_irq()" macro must not validate the if condition, because in the case the "spurious_page_fault()" function returns 0, a kernel panic is triggered. However, the "in_irq()" which gives the following assembly is user-controlled:

Now we control the "current" variable, which is contained in RAX. The index is retrieved in a field contained in the current structure which is used as an index in the irq_stat array. By providing an index of 0, the comparison succeeds and the check is bypassed, the function eventually returns 1 and leaves the "do_page_fault()" handler.

The code flow thus returns on the instruction right after the faulty instruction in "read_descriptor()" which triggered the #PF. The following instructions lead to a return 0.

The return value of "read_descriptor()" is then checked in "emulate_privileged_op()":

The "emulate_privileged_op()" function thus returns 0, the if condition is then skipped until the "go_guest_trap()" is reached, which is where things are getting interesting:

The "do_guest_trap()" function is responsible of propagating the #GP fault to the exception handler of the kernel. Since the hypervisor has been tricked into thinking that the exception is issued from ring3, it seems legit to transfer its handling to the kernel:

Here is where the magic happens. The current pointer is again used to initialize the trap_bounce structure. The addresses of the two structures are offsets from arch pointer which is a field of the current pointer. One can easily supply an arbitrary arch pointer such that the tb->cs and tb->eip will overlap with respectively the saved CS and RIP of the instruction after the SYSRET instruction which generated the #GP fault.

The "do_general_protection()" function will then return and eventually the following assembly code will be executed:

When the IRETQ instruction is reached, it will pop the user-controlled segment selector and perform a far jump to the user-controlled return address.

As stated earlier, the structures are located at user-controlled locations, so no hardcoded address is required, only offsets from structures are used. Thus reliable code execution is achieved with ring0 privileges.

3.2 - Code Execution in Host Context "dom0"

Since the exploit is performed from kernel land, which assumes that the attacker is already root on the guest virtual machine (legitimately or using a privilege escalation exploit), this sysret vulnerability can be exploited to target the dom0 virtual machine which is the most privileged domain, the only virtual machine which by default has direct access to hardware. From dom0, the hypervisor can be managed and unprivileged domains (domU) can be launched.

Under Citrix XenServer, dom0 is a 32-bit virtual machine, this configuration is used for performance reasons.

The strategy here will be to inject a dom0 root process with a bindshell (or reverse shell) payload in order to get a root shell from dom0. Trying to map dom0 pages directly by playing with page tables is not an easy task.

The same idea as in remote kernel exploitation will be used: hijack the interrupt 0x80 syscall handler in order to wait for an interruption from dom0 to occur. When an interrupt is triggered from dom0, one is assured that dom0 virtual pages are mapped into memory.

Xen is mapped at a static location in all the virtualized kernels in the same way that address 0xc0000000 is mapped in all 32-bit user land processes.

Since all Xen memory is mapped as RWX from the hypervisor point of view, one just has to overwrite an unused Xen location with a new int 0x80 handler and overwrite the Xen 0x80 entry in the IDT.

The 1st stage handler performs the following actions:

If a user land syscall is performed from dom0, the process context is saved and replaced by an argument performing a "mmap()" syscall with RWX permissions. The process EIP is set to return on an "int 0x80" instruction. The original "int 0x80" handler is then called.

After the syscall has successfully been executed, the process will return on the "int 0x80" instruction and perform a syscall with EAX having the value of the mmap()ed memory. The 2nd stage "int 0x80" handler is then reached: