VMware Backdoor ghi.guest.trashFolder.state 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 Workstation 7.0.0
  VMware Workstation 7.1.5 and earlier
  VMware Player 3.1.5 and earlier
  VMware ESXi 4.1.0 Update 2 Build 502767 and earlier
  Other related versions not tested due to unavailability


UNAFFECTED ENVIRONMENTS
-----------------------
VMware Server 1.0.x
VMware Server 2.0.x
VMware Workstation 8.0.x
VMware Player 4.0.x
VMware ESXi 3.5.0
VMware ESXi 4.0.0
VMware ESXi 5.0.0
Other related versions not tested due to unavailability


IDENTIFIERS
-----------
CVE-2012-1517


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.


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.  When the guest issues a command message, the
command dispatcher in the host VMX process calls a handler function
associated with the given command that is prototyped roughly as
follows:

  bool __cdecl CommandHandler(
    void *              unknown,
    short               channel,
    char *              args,
    unsigned int        args_len,
    char * *            preply,
    unsigned int *      preply_len)

The handler for the "ghi.guest.trashFolder.state" command, available
in newer versions of VMware products, checks for an empty argument
string by comparing 'args' to null and 'args_len' to zero, and if
either matches, the function fails with the error message "Invalid
parameters".  However, this particular failure path skips a call that
initializes a local variable, an XDR structure.  Before the handler
function returns--even in the event of failure--it retrieves the
'x_ops' pointer from the structure at offset +0x04 (32-bit) / +0x08
(64-bit), which points to a table of function pointers, and it then
calls the eighth function pointer, 'x_destroy', at offset +0x1C
(32-bit) / +0x38 (64-bit) within the table.


EXPLOITATION
------------
Since the stack memory that constitutes the structure remains
uninitialized when the handler function processes a
"ghi.guest.trashFolder.state" command with no arguments, the guest
could hypothetically proffer an arbitrary function pointer table
pointer by first causing some other operation to be performed by the
thread that will execute the handler function, thereby seeding that
portion of stack memory.  Successful exploitation would then depend on
being able to find or establish a useful function pointer table and
code to execute.

At least on a Windows host, procurement of a function pointer table
might be facilitated by the fact that the VMX executable cannot be
relocated.  Furthermore, the VMX process often features PAGE_READWRITE
mappings of guest physical memory at predictable addresses.  It might
also be possible to fill the VMX process's heap by issuing other
backdoor commands.


MITIGATION
----------
None known.


CONCLUSION
----------
This document discloses a vulnerability in more recent versions of
VMware products that could potentially allow a guest to execute
arbitrary code on the host system, although an unsuccessful
exploitation attempt will likely crash the guest.

The exploitability of this vulnerability is most contingent on the
ability to control the contents of the relevant, uninitialized stack
memory from the guest, which has not yet been demonstrated.  If that
proves to be possible, eventual reliable exploitation should be
considered likely.


GREETINGS
---------
www.ftmband.com
www.ridgewayis.com