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.
VMware Workstation Pro 12.5.7, Linux/Windows
7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE-772: Missing Release of Resource after Effective Lifetime
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.
# There are obviously better ways to do this for x in `seq 0 $(( 0xffffff/2 ))`; do echo “doop” | ncat <targetIP> <VNCPort>; done
2017-07-13 - Vendor Disclosure
2018-03-15 - Public Release
Discovered by Lilith <(-_-<) Wyatt of Cisco Talos