On September 15, VMware issued a notice that some versions of ESXi, Workstation and Fusion are affected by an out-of-bounds write vulnerability.
VMware makes virtualisation software that allows one computer (the host) to pretend to be one or more pseudo-computers (the guests).
Each guest is a “virtual machine” or VM that thinks it’s a real computer. The VMs are isolated from each other and the host by the virtualisation software.
That isolation is especially important in a hosting environment, where one physical server may provide virtual server instances to several different customers at the same time.
The out-of-bounds write vulnerability in VMware’s products allows guests to break out of their isolation—an attacker could escape the confines of a virtual machine and execute malicious code on the machine the VM is running on.
The impact of this vulnerability is potentially quite high, which is why VMware rates this vulnerability as critical; however, the Zero Day Initiative, which worked with the two researchers who discovered this issue to disclose it to VMware, gives this vulnerability only a medium score of 6.2.
The nuance behind ZDI’s reasoning is that while the impact is potentially high, this is not an easy vulnerability to exploit—it requires local access (either physical access or local shell), and the access complexity is high—in this case, the attacker must already be able to execute low-privilege code on the virtual machine to trigger this vulnerability.
Thankfully VMware issued a fix for this vulnerability (CVE-2017-4924 for those keeping track at home), so the standard advice of “patch ASAP” applies.
ESXi version 6.5, Workstation 12.x, and Fusion 8.x on OSX are all vulnerable to this bug, so update as soon as you can if you haven’t yet.
4 comments on “Critical VMware vulnerability, patch and update now”
the release date of the mentioned VMware patch is from Jul 27, 2017.
The article doesn’t list patches but it does say which product versions are vulnerable.
It also links to an advisory (VMSA-2017-0015.2), created 14 September and updated 18 September, that lists both the vulnerable products and the appropriate product versions or patches required to fix them.
yes, I know, but I cannot explain to me why VMware has such a big delay between patch release date and VMSA-2017-0015.2 create date/update (more than 40 days)
I formed the opinion that the bulletin only *seems* late – not all the supported versions of VMWare got the patches at the same time back in July.
I forget the specifics (with a lot of clicking you can find the timeline matrix for the various product flavours) but I think it was ESXi 5.5 [?] that got its patch for one of the security holes in the list about two months after the other product versions were patched.
One reason why we often write up “please check your patches” articles, even though you could argue that such articles are redundant after the vendor’s notifications appear, is that patching isn’t quite as easy as “someone fixed the code so we are all golden now”.
(Nowhere is this more evident than in the Android world, where Google will blithely report from orbit about how “XYZ remote code execution hole was promptly fixed in the code tree”, even though the actual patch may well only dribble its way down at stalactitic speeds to the billions of Android devices here on Planet Earth.)