CVE-2020-3941

The repair operation of VMware Tools for Windows 10.x.y has a race condition which may allow for privilege escalation in the Virtual Machine where Tools is installed. This vulnerability is not present in VMware Tools 11.x.y since the affected functionality is not present in VMware Tools 11.

Recent assessments:

bwatters-r7 at January 23, 2020 3:42pm UTC reported:

I played around trying to create a module for this, and it matches the original PoC put out by Polarbear. The way it works is that on a VM with the proper version of VMWare tools installed, you can run the repair operation and briefly, a trusted file in a trusted location (C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat) has permissions lowered. If an attacker can touch the file at the right time, they can maintain control over the file after the repair is over if the timing is right. The method to take that overwrite to SYSTEM is still as yet unreleased, as far as I can tell.

Defenders can watch for some obvious behaviors just in this process. The attacker has to run a specific command (msiexec /fa <installer file>), then while it is running, continually attempt to access a specific file (C:\ProgramData\VMware\VMware CAF\pme\scripts\stop-listener.bat), and once they control that file, they must include malicious code and somehow somehow run it resulting in a privilege escalation. Defenders can add this behavior to HIDS signatures as a stopgap.

This exploit relies on previous access, and results in further compromise of the VM. While important, there are challenges to get to a location that this exploit is useful, the required files represent a bottleneck on behavior, mitigations will not affect most users, the results are limited to the VM, and a patch is already out. Defenders should patch as soon as possible, and add mitigations quickly, but for this to be a problem, attackers must already have a foothold into the computer.

Assessed Attacker Value: 4
Assessed Attacker Value: 4Assessed Attacker Value: 3