VMware Backdoor ghi.guest.trashFolder.state Uninitialized Memory Potential VM Break

Type securityvulns
Reporter Securityvulns
Modified 2012-05-10T00:00:00


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


VMware, Inc.


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


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




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.


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.


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.


None known.


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.


www.ftmband.com www.ridgewayis.com