A few days ago, Core Security Technologies reported about a new vulnerability that was discovered in all versions of VMware's desktop products.
It normally takes some time until vendors release their patches. Meanwhile, most of the researchers have not much choice left as to wait.
Being armed with the knowledge that Core Security Labs researchers have shared with us, let’s give a quick look at what’s actually going on inside the VM host’s brains.
The trouble is caused with the way the executable file vmware-vmx.exe is making an API call MultiByteToWideChar(), as shown below when the executable is loaded into the disassembler:
Now, let’s run the VMWare Workstation (in this example, build # 6.0.2.59824 was used).
Inside the VM, we need to execute the code that relies on the exploit. On the host, you will need to run a debugger and attach it to the process vmware-vmx.exe.
Setting up a breakpoint is tricky, as it will be hit every time you move your mouse in the guest OS. Thus, you’ll need to disable the breakpoint, run the exploit code with some delay before it, then switch back into the host, and re-enable the breakpoint.
When the breakpoint is hit, right before the MultiByteToWideChar() API call is made at 0x00467DDE, the debugger window may look similar to:
As you may see, the parameter #1 is the Code Page. It’s specified as 0xFDE9, which is declared as CP_UTF8 in the header file Winnls.h.
Parameter #2, according to MSDN, is a flag that specifies how to deal with the invalid characters.
VMWare has this flag set to 8, declared as MB_ERR_INVALID_CHARS.
That’s how VMWare protects its users – if some nasty kid intentionally places some malformed characters, VMWare bets that this single flag will save us all by saying “Nah, your character is illegal – who are you trying to cheat here?”.
Let’s see what the parameter #3 is. It’s a pointer to the multi-byte string that needs to be converted. In our case, it's a malformed string.
The picture shows the contents of memory pointed by the 3rd parameter. Its ASCII representation looks Ok, excepting a few weird characters displayed on the place of 0xC2.
Now, let’s see if the API and the MB_ERR_INVALID_CHARS flag will protect us against such malformed string.
The picture below shows what happens after the MultiByteToWideChar() API call is made.
As seen on the picture, the malformed string has been perfectly converted. Moreover, 0xC2 characters became dots.
In the result of such conversion, the dot-dot syntax will provide an “escape” from the secured shared directory back up into the host’s parental directories, giving the exploit code full access to the host’s environment. This trick is known as a Directory Traversal Attack.
Obviously, if a malware researcher needs a practical solution that works now, the vmware-vmx.exe executable can be patched manually.
Firstly, the parent procedure from which the call occurs, may want to push 0x0FDE8 instead of 0x0FDE9. This will change the first parameter of the MultiByteToWideChar() API from CP_UTF8 to CP_UTF7. Thus, the malformed characters will not be converted into the dots – they’ll stay as they are, failing other checks down the execution flow.
Secondly, the second parameter responsible for the malformed string protection should be also be modified or otherwise the MultiByteToWideChar() function will fail.
The best bet, however, would be to wait for the official patch from the vendor. Let's hope their second attempt to patch this exploit has more luck than the first one.
