VMware Backdoor Response Uninitialized Memory Potential VM Break Derek Soeder ds.adv.pub@gmail.com 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