Share this…

As we approach Pwn2Own 2018, I’m reminded of some of the exploits we saw at last year’s contest. Of course, the most interesting bugs we saw involved guest-to-host escalation in VMware. Recently, we presented “l’art de l’évasion: Modern VMware Exploitation techniques” at OffensiveCon in Berlin (Hats off for the great conference!). The talk focused on exploitation techniques that have been used in the past year to exploit different vulnerability types in VMware Workstation. I’ve previously discussed Use-After-Free (UAF) VMware exploits affecting drag-and-drop (DnD) and triggered by Remote Call Procedure requests. If you haven’t read that blog yet, you may want to start there. Once you’re done with that blog, check out former Mobile Pwn2Own winner Amat Cama’s blog covering a heap-based buffer overflow exploit that Chaitin Security Research Lab planned to use at Pwn2Own last year. Unfortunately for them, the bug he describes was patched the day before the contest and thus couldn’t be used. Still, it’s a great write-up and should be considered foundational knowledge for VMware exploitation.

This blog builds off both of those topics by introducing the more complex exploitation technique of using uninitialized buffers and variables. Keeping with the Pwn2Own theme, my colleague Jasiel Spelman (@WanderingGlitch) and I had a look at what the folks from 360 Security used to execute code in the hypervisor from the guest OS, earning themselves $105,000 USD in the process. They leveraged a heap overflow in Microsoft Edge, a type confusion in the Windows kernel, and – most importantly – an uninitialized buffer in VMware Workstation for a complete virtual machine escape. It’s this specific bug that we detail here.

The bug

Before we explain the details of the bugs involved, here’s a quick video showing the full exploit chain in action:

The concept of uninitialized buffers and variables is simple: Variables are defined and are kept uninitialized.

Ideally, variables should be set to initial values:

But sometimes, they are not set to any values:

In the case of 360 Security’s SVGA uninitialized buffer vulnerability used at Pwn2Own 2017, a structure on the stack was kept uninitialized:

In this case, v2 – the beginning of a struct – was kept uninitialized. Later it was passed as an argument to sub_140151c20. If that function fails, then it will leave v2 untouched. Later, function sub_1403B69B0 is called with v2 as an argument. This function calls free against an offset of v2:

Exploitation of this vulnerability is not as trivial as a UAF vulnerability. Triggering this vulnerability requires elevation within the guest in order to be able to trigger it. In addition, because exploitation requires careful grooming of the stack contents, no other SVGA 3D operations can occur during this time.

We do not have direct control of the stack contents, but we do have enough control to get a useful primitive. Specifically, it is possible to call other functions to leave a valid pointer and valid flags on the stack such that we can successfully trigger the bug and thus trigger a free of a referenced object.

The plan of attack is the following:

In more detail, we’d have to trigger the vulnerability 4 times:

  1. Type Confusion
    Mob allocated
    Mob freed
    Struct allocated
    Struct freed
  2. Heap Address Leak
    Mob allocated
    Struct modified at offset of mob’s size
    Data copied to Surface, Surface copied to GMR
    Mob freed
  3. Function Pointer Leak
    Struct allocated
    Data copied to Surface, Surface copied to GMR
    Struct freed
  4. Code Execution
    Allocate ROP
    Replace function pointer
    Trigger call


Exploiting certain bug classes is not that hard in VMware – especially if they are RPC vulnerabilities. The mitigations game in VMware is still lacking. To put it in perspective, mitigations found in VMware Workstation seem similar to those found in web browsers 5 years ago. The only challenging part is finding the actual vulnerability. We’ve included VMware again as a target in our upcoming Pwn2Own competition. We’ll see if anyone shows up with new vulns then. If you’re looking for inspiration, check out these other recentpostsabout VMware bugs for more inspiration.