VMware addresses a DoS flaw in Workstation and Fusion products

[steven36]

VMware has addressed a denial-of-service (DoS) vulnerability, tracked as CVE-2018-6957, in its Workstation 12.x and 14.x and Fusion 10.1.1. and 10.x on OS X products.

 

 

The affected VMware solutions can be attacked by opening a large number of VNC sessions. The DoS vulnerability was discovered by Lilith Wyatt of Cisco Talos, the flaw could be exploited on Workstation and Fusion only if the VNC has been manually enabled.

 

VNC implementation in VMware solutions is used for remote management purposes.

 

“VMware Workstation and Fusion contain a denial-of-service vulnerability which can be triggered by opening a large number of VNC sessions.” reads the security advisory published by VMware.

 

The company issued the security patches in Workstation 14.1.1 and Fusion 10.1.1.,  VMware also shared details about a workaround for Workstation 12.x and Fusion 8.x releases that involves setting a password for the VNC connection.

 

While VMware has classified the vulnerability as “important,” Cisco Talos has ranked it as a “high severity” flaw and assigned it a CVSS score of 7.5.

 

Experts at Cisco Talos confirmed that an attacker can trigger the flaw on a targeted server and cause the virtual machine to shut down by opening a large number of VNC sessions.

 

“Since the VMware VNC server is naturally multi-threaded, there are locks and semaphores and mutexes to deal with shared variables.” reads the advisory published by Talos.

 

“The VNC server also maintains a global variable that indicates the amount of locks that are currently used, that is incremented by certain events.”

 

Talos published the Proof-of-Concept exploit code:

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

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.” continues Talos.

 

“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.”

 

Below the timeline for the flaw:

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

 

Source