Invalid #PF Exception Code in VMware can result in Guest Privilege Escalation

Invalid #PF Exception Code in VMware can result in Guest Privilege Escalation

In protected mode, cpl is usually equal to the two least significant bits of
the cs register. However, there is an exception: in Virtual-8086 mode, the
cpl is always 3 (least privileged), regardless of the value of the cs
register.

When the processor raises a #PF (page fault) exception, an exception code is
pushed onto the stack containing flags used by the operating system to
determine the correct course of action. One of those flags is called U/S
(user/supervisor), which is set if the fault was caused while the processor
was in user mode.

In Virtual-8086 mode, when VMware emulates a far call or far jmp instruction,
it incorrectly pushes the return cs and ip on the stack using supervisory
access, causing an incorrect exception code to be delivered to the guest
kernel.

As Virtual-8086 mode allows userland code to specify an arbitrary cs register,
including the two least significant bits, an attacker can use this supervisory
access to confuse the kernel, allowing escalation of privileges.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CVE-2009-2267 to this issue.

---

Affected Software

• VMware Workstation
• VMware Player
• VMware ACE
• VMware Server
• VMware ESX
• VMware Fusion
• Etc.

---

Consequences

We have successfully exploited this issue on Linux guests. Other guest
operating systems may also be exploitable.

Here is what happens on an up-to-date Ubuntu Linux 8.04 guest when the kernel
handles the #PF exception with a spoofed supervisor bit in the exception code.

(gdb) x/i $pc
0x900: call 0xaabb:0xccdd
(gdb) si
0xc031d000 in page_fault ()
(gdb) x/x $esp
0xdde15f08: 0x00000002
(gdb) x/t $esp
0xdde15f08: 00000000000000000000000000000010

Examining the condition code (error_code in the snippet below), you can see it
was caused by a data write (i.e. not an instruction fetch, the cs/eip push) in
supervisor mode to a non-present page. This is incorrect.

http://lxr.linux.no/linux+v2.6.24/arch/x86/mm/fault_32.c#L461

461 /* User mode accesses just cause a SIGSEGV /
462 if (error_code & 4) {
…
507no_context:
508 / Are we prepared to handle this kernel fault? */
509 if (fixup_exception(regs))
510 return;

With a spoofed cs register, this can lead to this path (see the
SEGMENT_IS_PNP_CODE macro from segment_32.h), causing the kernel to
reach the pnp_bios_is_utter_crap code, and attempting this recovery:

http://lxr.linux.no/linux+v2.6.24/arch/x86/mm/extable_32.c#L20

19 printk(KERN_CRIT "PNPBIOS fault… attempting recovery.\n");
20 asm volatile(
21 "movl %0, %%esp\n\t"
22 "jmp *%1\n\t"
23 : : "g" (pnp_bios_fault_esp), "g" (pnp_bios_fault_eip));
24 panic("do_trap: can't hit this");
25 }

pnp_bios_fault_eip and pnp_bios_fault_esp are both .bss objects, and
will be initialised to NULL. Thus, line 22 will transfer execution to
the first page.

Therefore, incorrectly reporting the supervisor bit can lead to a local
ring3->ring0 privilege escalation in guests.

/* … */
// Setup registers
vm.regs.eflags = EFLAGS_TF_MASK;
vm.regs.esp = 0xDEADBEEF;
vm.regs.eip = 0x00000000;
vm.regs.cs = 0x0090;
vm.regs.ss = 0xFFFF;

CODE16("call 0xaabb:0xccdd", code, codesize);

vm86(Vm86Enter, &vm);

/* … */

The attached non-weaponised proof of concept demonstrates this by
printing a message to the console from ring0.

---

Solution

Updated software is available from the vendor at http://www.vmware.com/

http://www.vmware.com/security/advisories/VMSA-2009-0015.html

---

Credit

This bug was discovered by Tavis Ormandy and Julien Tinnes of the Google
Security Team.

---

Greetz

Greetz to Lcamtuf, LiquidK, redpig, Neel, pipacs, spoonm, asiraP,
Jagger, and our other elite colleagues.

Additional greetz to everyone at $1$K2XTi4ZA$H5Y197fbrMk85ZWzNw/Nm0.

Enjoy some photography while at ring0 @ http://flickr.com/meder

–

[email protected] | finger me for my gpg key.