Memory Corruption in vmware-vmx.exe

September 30, 2022

By: Christopher Vella

Memory Corruption in vmware-vmx.exe | Signal Labs | Advanced Offensive Cybersecurity Training | Self-Paced Trainings | Live Trainings | Virtual Trainings | Custom Private Trainings for Business

Preface: Hypervisor Bugs?

Firstly — while the below is a memory corruption bug in VMware’s vmware-vmx.exe process, it is benign (not quite exploitable, partly why I’m comfortable dropping it here) but it is fun to talk about and came from personal VMware fuzzing adventures.

The Bug: A Tale of Two

To first reach the memory corruption bug, we have to take vmware-vmx.exe down the path of panicking!

This is because the actual memory corruption lives in VMware’s zlib.dll, this module is used when vmware-vmx.exe encounters an error and proceeds to create a crash-dump of itself and compress that to disk.

Snippet of the coredmp logic in vmware-vmx’s panic handler

Looking at xref’s to vmware’s panic handler, there’s quite a few ways to make the vmware-vmx process panic.

Over 4k xrefs!

We just need to hit one! How can we do this? We need our first bug to hit the panic handler!

Turns out my VMware fuzzer found such a bug, and its in the LSI Logic handler in the process, in particular this line:

Yes, I am coverage-guided fuzzing btw

So this initial bug isn’t anything crazy, its essentially an ASSERT due to unexpected/malformed input, this bug alone will just crash our own VM and as such doesn’t really constitute a bug itself (unless you can do something else with it, I had ideas of continually restarting/crashing my own VM to take up crash-dump / log space on the host for instance)

However my fuzzer didn’t report this as an ASSERT, it found an actual memory corruption bug! Turns out during the panicing process in this instance data is sent to VMware’s zlib’s deflate function (for compression) and this code actually has an overflow read!

What happens here is that a buffer is looped over a set of iterations and for each iteration we read 8 bytes from the buffer, however it goes one iteration too far and attempts to read past the bounds of the buffer on the final iteration:

Oopsie!

Repro for Yourself

Want to test this yourself? Grab the bootx64.efi (uefi bootloader) I’ve made below, you can create a VMware vmdk and plant this in the vmdk’s “\EFI\Boot” folder, such that when you mount the vmdk the structure is “\EFI\Boot\bootx64.efi”.

When you launch the VM my bootloader will run and repro the crash for you (its not a 100% success rate, probably about 80%).

bootx64.efi: https://github.com/Kharos102/VmwareBlogBug

Brand Icon Seperator | Signal Labs | Advanced Offensive Cybersecurity Training | Self-Paced Trainings | Live Trainings | Virtual Trainings | Custom Private Trainings for Business

Empowering Cyber Defense with Advanced Offensive Security Capabilities

Signal Labs provides self-paced and live training solutions, empowering our learners to acquire the latest cutting-edge skills in this rapidly evolving field. Improve your vulnerability research campaigns and adversary simulation capabilities with the latest in offensive research and techniques.

Stay Connected

We'll let you know when our next live training is scheduled.

Stay Connected

We'll let you know when our next live training is scheduled.

Stay Connected

We'll let you know when our next live training is scheduled.

Stay Connected

We'll let you know when our next live training is scheduled.