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