Exploit the possiblities

VMware Backdoor Response Uninitialized Memory Potential VM Break

VMware Backdoor Response Uninitialized Memory Potential VM Break
Posted May 6, 2012
Authored by Derek Soeder

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.

tags | exploit, arbitrary, kernel, code execution
systems | windows
advisories | CVE-2012-1516
MD5 | 2ef8f66ab0e238a9620ce20fe03c5f8f

VMware Backdoor Response Uninitialized Memory Potential VM Break

Change Mirror Download
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

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

November 2017

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    22 Files
  • 2
    Nov 2nd
    28 Files
  • 3
    Nov 3rd
    10 Files
  • 4
    Nov 4th
    1 Files
  • 5
    Nov 5th
    5 Files
  • 6
    Nov 6th
    15 Files
  • 7
    Nov 7th
    15 Files
  • 8
    Nov 8th
    13 Files
  • 9
    Nov 9th
    9 Files
  • 10
    Nov 10th
    9 Files
  • 11
    Nov 11th
    3 Files
  • 12
    Nov 12th
    2 Files
  • 13
    Nov 13th
    15 Files
  • 14
    Nov 14th
    17 Files
  • 15
    Nov 15th
    19 Files
  • 16
    Nov 16th
    15 Files
  • 17
    Nov 17th
    19 Files
  • 18
    Nov 18th
    0 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    0 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    0 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close