VMware Backdoor Response Uninitialized Memory Potential VM Break

`VMware Backdoor Response Uninitialized Memory Potential VM Break  
  
Derek Soeder  
[email protected]  
  
Reported: December 5, 2011  
Published: May 3, 2012  
  
  
AFFECTED VENDOR  
---------------  
VMware, Inc.  
  
  
AFFECTED ENVIRONMENTS  
---------------------  
The following VMware product versions are known to be affected:  
VMware Server 1.0.10  
VMware Server 2.0.2 and earlier  
VMware Workstation 7.0.0  
VMware Workstation 7.1.5 and earlier  
VMware ESXi 3.5.0 Update 5 and earlier  
VMware ESXi 4.0.0 Update 2 and earlier  
VMware ESXi 4.1.0 Update 1 Build 433742 (ESXi410-201107401-BG) and earlier  
Other related versions not tested but assumed to be affected  
  
  
UNAFFECTED ENVIRONMENTS  
-----------------------  
VMware Workstation 8.0.x  
VMware Player 4.0.x  
VMware ESXi 4.0.0 Update 3 and later  
VMware ESXi 4.1.0 Update 2  
VMware ESXi 5.0.0 and later  
  
  
IDENTIFIERS  
-----------  
CVE-2012-1516  
  
  
IMPACT  
------  
The vulnerability described in this document could hypothetically be  
exploited by unprivileged code running in a VMware virtual machine  
(guest) in order to execute code in the host VMX process, thereby  
breaking out of the virtual machine; however, such exploitation has  
not been proven. In the event that arbitrary code execution in the  
VMX process is possible, kernel privileges can be obtained on a  
Windows host by abusing the VMX process's special access to a VMware  
driver, meaning the maximum possible impact of this vulnerability is  
elevation from unprivileged guest code execution to host kernel code  
execution.  
  
  
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. Messages from the guest take the form of a command string  
followed by any number of arguments, while the responses from the host  
consist of a return code (the character '1' to indicate success, or  
'0' to indicate failure), followed by a space, followed by an optional  
error message string.  
  
When the guest issues a command message, the command dispatcher in the  
host VMX process searches an internal table for an entry corresponding  
to the given command. If a matching entry is found and is marked as  
enabled, the dispatcher calls the associated handler function, which  
is prototyped roughly as follows:  
  
bool __cdecl CommandHandler(  
void * unknown,  
short channel,  
char * args,  
unsigned int args_len,  
char * * preply,  
unsigned int * preply_len)  
  
Once the handler function returns, the dispatcher malloc's a buffer of  
(*preply_len + 3) bytes, into which it stores the status code and  
memcpy's the reply string, and then it prepares the resulting string  
for retrieval by the guest.  
  
The local variables in the dispatcher's stack frame referenced by  
'preply' and 'preply_len' are not initialized prior to invocation of  
the handler function. If the handler function returns without  
assigning to these variables, then the dispatcher will call malloc and  
memcpy with sizes and a source pointer based on whatever values happen  
to reside in the uninitialized variables.  
  
As a matter of fact, handler functions featuring code paths that fail  
to set these variables do exist. The following command strings can  
elicit the vulnerable behavior:  
  
"VMXI_Proxy_Msg"  
VMware Server 1.0.10 and earlier  
  
"VIX_Proxy_Msg"  
VMware Server 2.0.2 and earlier  
VMware Workstation 7.0.0  
VMware Workstation 7.1.5 and earlier  
VMware ESXi 3.5.0 Update 5 and earlier  
VMware ESXi 4.0.0 Update 2 and earlier  
VMware ESXi 4.1.0 Update 1 and earlier  
  
"unity.operation.request XXX"  
VMware Workstation 7.0.0  
VMware Workstation 7.1.5 and earlier  
  
The handler function for the "VIX_Proxy_Msg" command (originally named  
"VMXI_Proxy_Msg") contains a failure path that will leave the  
variables uninitialized if VIX is disabled for the virtual machine,  
which is the case if the "vix.inGuest.enable" setting is absent from  
or set to "FALSE" in the virtual machine's .vmx configuration file.  
The "unity.operation.request" handler function will fail without  
initializing the variables in question if it receives a non-empty  
argument string that it cannot deserialize.  
  
If the guest can seed stack memory by causing some other operation to  
be performed on the thread that will execute the dispatcher function,  
it should permit the guest to read arbitrary VMX process memory, or  
worse, cause an approximately 4GB heap overflow with potentially  
arbitrary data.  
  
  
EXPLOITATION  
------------  
Due to 32-bit integer overflow (32-bit integer truncation in 64-bit  
builds of the VMX executable), a '*preply_len' of -3 (0xFFFFFFFD), -2  
(0xFFFFFFFE), or -1 (0xFFFFFFFF) will produce a minimal malloc  
followed by a roughly 4GB memcpy into the allocated buffer.  
Successful exploitation of this vulnerability, then, requires that the  
guest be able to supply the value of '*preply_len', cause '*preply' to  
point to usable data, initiate arbitrary code execution in the VMX  
process, and accomplish any intended objective before the process  
crashes from the excessive memcpy and concomitant heap corruption.  
Assuming that reliable control of the uninitialized memory is  
possible, preliminary exploitation of the vulnerability for the  
purpose of reading VMX process memory (by specifying an arbitrary  
source pointer and a reasonable size) could facilitate reconnaissance  
in preparation for a breakout.  
  
  
MITIGATION  
----------  
The following workarounds only prevent exploitation by a malicious  
user confined to the guest; they will not prevent an unprivileged  
malicious user on a Windows host from exploiting the vulnerability for  
local privilege elevation to kernel, as it is assumed that such a user  
could create a virtual machine with a configuration of his choosing,  
enter the virtual machine, and then exploit the vulnerability to take  
over the VMX process, which permits elevation to kernel.  
  
* Disable the "VIX_Proxy_Msg" command  
  
The "VIX_Proxy_Msg" command can be disabled in a specific guest by  
adding the following line to the virtual machine's .vmx configuration  
file:  
  
isolation.tools.vixMessage.disable = "TRUE"  
  
If the guest attempts to issue the command, it will receive an  
"Unknown command" error response instead of executing the  
corresponding handler function on the host. It is not known if  
disabling this command disrupts VIX functionality. Note that this  
workaround does not disable the "VMXI_Proxy_Msg" command of VMware  
Server 1.0.x, and it has not been tested on other old versions of  
VMware products.  
  
* Disable the "unity.operation.request" command  
  
The "unity.operation.request" command can be disabled in a specific  
guest by adding the following line to the virtual machine's .vmx  
configuration file:  
  
isolation.tools.unityInterlockOperation.disable = "TRUE"  
  
Note that this also disables the "unity.operation.ack" command. If  
the guest attempts to issue either disabled command, it will receive  
an "Unknown command" error response instead of executing the  
corresponding handler function on the host. It is not known if  
disabling these commands disrupts any Unity functionality.  
  
* Enable VIX  
  
Enabling VIX causes the "VMXI_Proxy_Msg" / "VIX_Proxy_Msg" handler  
function to avoid the vulnerable failure path, but might expose  
additional attack surface. To enable VIX for a virtual machine, add  
the following line to the virtual machine's .vmx configuration file:  
  
vix.inGuest.enable = "TRUE"  
  
  
CONCLUSION  
----------  
This document describes a vulnerability in most or all VMware products  
that could potentially allow a guest to execute arbitrary code on the  
host system, although even a successful attempt would almost certainly  
crash the guest in the process. Considering the unproven prerequisite  
of controlling the uninitialized local variables, and the  
unpredictability and probable time-sensitivity of the subsequent heap  
overflow, successful and especially reliable exploitation of this  
vulnerability may seem unlikely, but it cannot be ruled out.  
  
  
GREETINGS  
---------  
www.ftmband.com  
www.ridgewayis.com  
`