VMware High-Bandwidth Backdoor ROM Overwrite Privilege Elevation

`VMware High-Bandwidth Backdoor ROM Overwrite Privilege Elevation  
  
Derek Soeder  
[email protected]  
  
Reported: December 5, 2011  
Published: March 30, 2012  
  
  
AFFECTED VENDOR  
---------------  
VMware, Inc.  
  
  
AFFECTED ENVIRONMENTS  
---------------------  
The following VMware product versions are known to be affected:  
VMware Server 1.0.10 and earlier  
VMware Server 2.0.2 and earlier  
VMware Workstation 7.0.0  
VMware Workstation 7.1.1 and earlier  
VMware ESXi 3.5.0 Update 5  
VMware ESXi 4.0.0 Update 4 Build 504850 and earlier  
VMware ESXi 4.1.0 Build 320137 (ESXi410-201011401-BG) and earlier  
Other related versions not tested but assumed to be affected  
  
The following guest operating systems are known to enable exploitation:  
Windows NT 4.0  
Windows 2000  
Windows XP (32-bit)  
Windows Server 2003 (32-bit)  
  
  
UNAFFECTED ENVIRONMENTS  
-----------------------  
The following VMware product versions are not affected:  
VMware Workstation 7.1.2 and later  
VMware ESXi 4.0.0 Update 4 with patch ESXi400-201203401-SG  
VMware ESXi 4.1.0 Update 1 Build 348481 (ESXi410-201101201-SG) and later  
VMware ESXi 5.0.0  
  
The following guest operating systems do not appear to permit exploitation:  
Windows XP (64-bit)  
Windows Server 2003 (64-bit)  
Windows Vista (32-bit and 64-bit)  
Windows Server 2008 (32-bit and 64-bit)  
Windows 7 (32-bit and 64-bit)  
Windows Server 2008 R2  
  
  
IDENTIFIERS  
-----------  
CVE-2012-1515  
  
  
IMPACT  
------  
The vulnerability described in this document can be exploited by  
unprivileged code running on certain guest operating systems in a  
VMware virtual machine in order to execute arbitrary code with kernel  
privileges.  
  
  
VULNERABILITY DETAILS  
---------------------  
The VMware backdoor interface consists of a number of operations  
issued via I/O instructions executed in the guest with a command  
number in CX and data or "magic" values in a number of other  
registers. Command 0x1E / 30 (BDOOR_CMD_MESSAGE) and its subcommands  
(MESSAGE_TYPE_*) allow messages to be exchanged between the guest and  
host. Since the regular backdoor would only allow for the exchange of  
no more than one machine word of data per I/O instruction, a  
"high-bandwidth" backdoor exists on port 0x5659 (BDOORHB_PORT) to  
permit bulk transmission of data from and to the guest via the REP  
OUTSB and REP INSB instructions respectively. If the direction flag  
is clear, the host performs the transfer by memcpy'ing directly from  
or to its mapping of guest memory, after performing any applicable  
address translations and memory access checks.  
  
One special case that the host fails to consider, however, is when a  
REP INSB is targeting memory that would normally be emulated as  
read-only. If the guest operating system allows an unprivileged user  
to address a writable view of read-only memory, the user can exploit  
this vulnerability to modify the ROM's contents whereas he otherwise  
could not. To then parlay this ability into a successful attack  
requires causing privileged code that trusts the ROM to act on the  
altered contents in an exploitable way.  
  
  
EXPLOITATION  
------------  
Only 32-bit editions of Windows prior to Vista allow an unprivileged  
user to map a PAGE_READWRITE view of the BIOS ROM by launching a  
Virtual DOS Machine (NTVDM.EXE). On 32-bit Windows Vista and Windows  
Server 2008, NT!VdmpInitialize is hard-coded to map physical addresses  
0xC0000 through 0xFFFFF at the corresponding virtual addresses as  
PAGE_READONLY, while 32-bit Windows 7 allocates writable virtual  
memory at 0xC0000 and copies in the contents of the BIOS ROM, and VDM  
support does not exist at all in 64-bit editions of Windows.  
(Presumably, ROM was originally mapped as writable so that 16-bit code  
that tried for any reason to write to ROM could do so and have it  
silently fail while still causing the expected side effects like  
updating the flags. One wonders what prompted the change on Vista.)  
  
Although this vulnerability allows modification of the in-guest BIOS  
ROM, there seem to be few opportunities to get Windows to execute  
modified BIOS code. One possible attack involves putting the modified  
code in place and initiating or waiting for a soft reboot, after which  
the planted code would execute and could mount a BootRoot-style attack  
to alter the guest kernel as it loads. Another possibility is to  
modify BIOS code and wait for some other user to run a 16-bit program  
that changes the video mode or makes an exotic BIOS call unhandled by  
NTVDM, but this is obviously flimsy. The third and best possibility,  
discussed below, is to cause the kernel to change the video mode,  
which will execute an INT 10h instruction from one of two Virtual-8086  
mode environments, either of which can be escaped to infiltrate the  
kernel.  
  
As the author mentioned in the advisory for CVE-2007-1206 (which  
allowed modification of the Interrupt Vector Table rather than the  
BIOS code it references), HAL.DLL will issue an INT 10h to prepare for  
hibernation or a blue-screen, both of which could be considered "local  
denial-of-service" conditions. However, the author has since found  
that requesting full-screen text mode or switching to a VGA display  
mode will also cause the INT 10h handler to be executed, although by  
NTOSKRNL.EXE rather than HAL. Rough reverse call trees for both are  
depicted below:  
  
HAL!HalpBiosCall  
^ HAL!HalpBiosDisplayReset (via NT!HalPrivateDispatchTable)  
. ^ BOOTVID!VidResetDisplay  
. . ^ NT!VidResetDisplay  
. . . ^ NT!InbvResetDisplay  
. . . . ^ NT!KeBugCheck2  
. . . . . ^ (blue-screen)  
. . . . ^ HAL!InbvResetDisplay  
. . . . . ^ HAL!HalHandleNMI  
. . . . . . ^ NT!KiTrap02  
. . . . . . . ^ (catastrophe)  
. . . . ^ NT!PopSaveHiberContext (via DPC)  
. . . . . ^ NT!PopInvokeSystemStateHandler  
. . . . . . ^ NT!PopShutdownSystem  
. . . . . . . ^ NT!PopGracefulShutdown  
. . . . . . . . ^ NT!NtSetSystemPowerState  
. . . . . . . . . ^ NT!NtShutdownSystem  
. . . . . . ^ NT!PopSleepSystem  
. . . . . . . ^ NT!NtSetSystemPowerState  
. . . . . . . . ^ NT!NtShutdownSystem  
  
NT!Ke386CallBios  
^ VIDEOPRT!Ke386CallBios  
. ^ VIDEOPRT!VideoPortInt10  
. . ^ VGA!VgaSetMode  
. . . ^ VGA!VgaStartIO  
. . . . ^ VIDEOPRT!pVideoPortDispatch  
. . . . . ^ NT!IofCallDriver  
. . . . . . ^ WIN32K!GreDeviceIoControl  
. . . . . . . ^ WIN32K!EngDeviceIoControl  
. . . . . . . . ^ (...)  
. . . . . . . . . ^ WIN32K!DrvChangeDisplaySettings  
. . . . . . . . . . ^ WIN32K!xxxUserChangeDisplaySettings  
. . . . . . . . . . . ^ WIN32K!NtUserChangeDisplaySettings  
. . . . . . . . . . . . ^ USER32!NtUserChangeDisplaySettings  
. . . . . . . . . . . . . ^ USER32!ChangeDisplaySettings*  
. . . . . . . . ^ (...)  
. . . . . . . . . ^ WIN32K!xxxbFullscreenSwitch  
. . . . . . . . . . ^ WIN32K!xxxConsoleControl  
. . . . . . . . . . . ^ WIN32K!NtUserConsoleControl  
. . . . . . . . . . . . ^ WINSRV!NtUserConsoleControl  
. . . . . . . . . . . . . ^ WINSRV!ChangeDispSettings  
. . . . . . . . . . . . . . ^ WINSRV!HandleSysKeyEvent  
. . . . . . . . . . . . . . . ^ WINSRV!ConsoleWindowProc  
. . . . . . . . . . . . . . . . ^ (...)  
. . . . . . . . . . . . . . . . . ^ NTDLL!CsrClientCallServer  
. . . . . . . . . . . . . . . . . . ^ KERNEL32!SetConsoleDisplayMode  
. . ^ VIDEOPRT!VpInt10CallBios  
. . . ^ VGA!GetVideoMemoryBaseAddress  
. . . . ^ VGA!VgaSetMode  
. . . . . ^ (...)  
  
As suggested above, unprivileged code can cause execution of the BIOS  
INT 10h handler from either HAL or NTOSKRNL, the former through a  
blue-screen or shutdown (such as hibernation), and the latter by  
changing the video mode, which requires console access. Assuming that  
malicious code has access to the console, and assuming that the video  
driver does not prevent it (as the VMware Tools video driver in some  
cases does), the malicious code could call ChangeDisplaySettings[Ex]  
or SetConsoleDisplayMode to force a video mode change without needing  
SeShutdownPrivilege or an independent blue-screen flaw. The following  
paragraphs cover exploitation in both the HAL and NTOSKRNL cases,  
starting from the assumption that an attacker has already modified the  
BIOS's INT 10h handler code.  
  
To infiltrate the kernel when invoked via HAL!HalpBiosCall, the  
malicious INT 10h handler code can simply modify the pages of memory  
containing HAL!HalpRealModeStart, the V86-mode stack, and  
HAL!HalpRealModeEnd, which HAL!HalpBiosDisplayReset maps with write  
permissions at virtual address 0x20000. Once execution returns to  
HAL!HalpRealModeEnd following attempted execution of the C4h/C4h  
sequence, the attacker will be executing code in the familiar Windows  
kernel environment, albeit with some cleanup necessary. Malicious  
code might detect the HAL case by observing if SS = 0x2000.  
  
Infiltrating the kernel from the NT!Ke386CallBios environment, on the  
other hand, is a little more indirect. NTOSKRNL issues an INT 10h  
from a proper VDM with no interesting kernel code targets, but the VDM  
TIB is accessible to V86-mode code (at address 0x12000). The  
malicious INT 10h handler can modify the kernel stack pointer stored  
in 'CONTEXT.Esi', just as described in Tavis Ormandy's CVE-2010-0232  
advisory ("Microsoft Windows NT #GP Trap Handler Allows Users to  
Switch Kernel Stack"), in order to hijack execution after the cleanup  
code at NT!Ki386BiosCallReturnAddress completes. Malicious code might  
detect the NTOSKRNL case by checking for SS = 0x1000.  
  
Of course, none of this matters without the ability to meaningfully  
modify BIOS code. Malicious code in the guest can only modify ROM  
through the high-bandwidth backdoor REP INSB instruction, meaning it  
can only overwrite ROM with bytes it can read from the host. Although  
VMware Server 1.0 permits the guest to read host stack memory beyond  
the end of any host-to-guest message, which allows reading of (and  
therefore overwriting with) arbitrary bytes by first "seeding" the  
buffer with a long REP OUTSB, a more version-independent approach is  
to first use the "info-set" command to store an arbitrary low-byte  
string in the VMDb "guestinfo" database, and then use "info-get" to  
read the string from the host and overwrite the desired portion of  
guest ROM.  
  
The author's proof-of-concept exploit uses this technique to implement  
a six-stage approach, comprising: (1) the replacement INT 10h handler,  
a tiny, low-byte arithmetic / PUSH / Jcc sequence that computes the  
offset of the next stage, pushes it, and branches to a nearby RET,  
RETF, or IRET; (2) a larger, low-byte sequence stored over the 8x8  
graphics font table (hopefully in video BIOS ROM pointed to by the INT  
1Fh vector) that computes the bytes of the next stage, pushes them  
onto the stack, and branches to a nearby RETF or IRET; (3) a small,  
base-64-like decoder that decodes and executes the next stage, which  
was also stored in the font table; (4) a loader that reads the  
subsequent stages into RAM from the "guestinfo" database via the  
VMware backdoor interface, decodes them, and executes the next stage;  
(5) the main V86-mode payload, which prepares the next stage to  
execute in ring 0 using the appropriate, aforementioned HAL or  
NTOSKRNL infiltration technique; and (6) the main kernel payload,  
which creates an interrupt gate for convenient kernel access and  
cleans up the environment so that execution can resume without  
crashing. The Win32 portion of the exploit can then use the interrupt  
gate as needed.  
  
With ring-0 privileges, the payload can restore the original contents  
of BIOS ROM (assuming it preserved them) by making ROM writable via  
PCI configuration space. In the eight bytes of PCI configuration  
space starting at address 0x80000058, bit 0 and bit 4 each indicate  
whether or not a segment of BIOS ROM is mapped, and bits 1 and 5  
determine whether or not those segments are writable. Setting the  
writable bits for all mapped segments, then, allows the ROM to be  
directly overwritten with arbitrary bytes, as opposed to being  
overwritten indirectly and only with low bytes through re-exploitation  
of the vulnerability.  
  
Another ramification of exploitation requiring rectification is the  
unavoidable change in video mode. Before it invokes the INT 10h  
handler, the kernel has already changed the display mode and  
consequently blacked out the screen, so programming the malicious  
handler to return without executing the original handler doesn't help  
and could actually make it more difficult to properly restore the  
display. One easy means of recovering from the mode change is to  
inject code into session 0's WINLOGON.EXE process that enumerates  
desktops and calls "ChangeDisplaySettings(NULL, CDS_RESET)" while  
attached to each, although some amount of display flickering is  
nevertheless inevitable.  
  
  
MITIGATION  
----------  
  
* Disable NTVDM in the guest operating system  
  
Disabling Virtual DOS Machine (NTVDM) support in the guest should deny  
an unprivileged user the ability to obtain a writable mapping of ROM  
on affected versions of Windows, thereby preventing exploitation of  
the vulnerability. To disable NTVDM, follow the guidance presented in  
one of the following Microsoft Knowledge Base Articles:  
  
http://support.microsoft.com/kb/979682  
http://support.microsoft.com/kb/220159  
  
Or, manually set the "VDMDisallowed" registry value, which is  
mentioned on the following page: (Note that this registry value is  
not recognized by all versions of Windows.)  
  
http://technet.microsoft.com/en-us/library/cc783069.aspx  
  
Be aware that disabling NTVDM will break 32-bit applications that rely  
on DOS functionality, in addition to 16-bit applications.  
  
* Run untrusted programs in a Remote Desktop session, and do not allow  
the guest to power down or restart  
  
The most likely exploitation scenarios require that the attack code be  
able to trigger a kernel BIOS call, which is most easily accomplished  
by changing the guest's video mode. Running suspect code in a Remote  
Desktop session--as opposed to a console session--prevents the code  
from changing the video mode, thereby reducing the likelihood of  
successful elevation to kernel privileges. (Of course, make sure that  
dangerous Remote Desktop features, such as local drive sharing, are  
disabled when running untrusted code in this way.)  
  
Another feasible exploitation scenario involves overwriting the BIOS  
and then causing a shutdown, a restart, or hibernation. Run untrusted  
code in the guest as an unprivileged user without shutdown privileges,  
and force the virtual machine to power down afterwards; do not allow  
the guest to gracefully power down or restart, as that might give  
modified code an opportunity to execute.  
  
Because this workaround does not prevent modification of BIOS ROM,  
malicious code could still attempt to exploit the vulnerability by  
causing a blue-screen or planting code for other users' VDMs to  
execute.  
  
* Disable the "info-get" and "info-set" commands  
  
Exploitation depends on the attacker being able to overwrite ROM with  
the contents of backdoor command responses, which the "info-set" and  
"info-get" commands facilitate by allowing the attacker to store and  
retrieve arbitrary data. These commands can be disabled in a specific  
guest by adding the following lines to the virtual machine's .vmx  
configuration file:  
  
isolation.tools.getInfo.disable = "TRUE"  
isolation.tools.setInfo.disable = "TRUE"  
  
Note that the second line also disables the "SetGuestInfo" command.  
It is not known if disabling these commands disrupts any guest  
monitoring or other VMware Tools functionality.  
  
* Restrict access to the VMware backdoor interface  
  
Adding the following line to the virtual machine's .vmx configuration  
file will prevent unprivileged code (code with CPL > IOPL) from  
accessing the VMware backdoor interface, rendering the vulnerability  
unexploitable for the sake of privilege elevation:  
  
monitor_control.restrict_backdoor = "TRUE"  
  
With this setting in place, an unprivileged attempt to execute a  
VMware backdoor port I/O instruction will result in a privileged  
instruction exception. Note that this setting crashes the user-mode  
portion of VMware Tools, and thus disrupts certain features such as  
guest-host copy-and-paste and drag-and-drop.  
  
  
CONCLUSION  
----------  
This document discloses a guest privilege elevation vulnerability  
arising from fairly arcane behavior of VMware's backdoor interface,  
and makes a case for its exploitability by presenting at a high level  
the steps performed by the author's own functioning proof of concept.  
  
It is not known if other machine virtualization software is  
susceptible to similar issues regarding incomplete emulation of  
read-only memory.  
  
  
GREETINGS  
---------  
www.ridgewayis.com  
www.ftmband.com  
`