Affected products include ESX and ESXi versions 3.5, 4.0, 4.1 and 5.0, Workstation and Player. A further description of problems associated with the patches and linked from the security update blog describes remote procedure call (RPC), SCSI driver and network file system (NFS) vulnerabilities which could potentially allow an unauthorized user execute code on a virtualized host.
With the post’s repeated use of the word “critical,” and widespread Tweeting of a link to it by VMware officials, it’s clear the patches are important. In fact, such a security update hasn’t been posted on the VMware Security and Compliance Blog since the announcement of a critical update to ESX 3.5 in 2008.
Though the post referred directly to the leak incident, what’s less clear is the exact relation of these newly announced vulnerabilities and the leaked source code file.
VMware framed the security advisory as the accelerated release of patches the company was working on anyway. “In light of the current circumstances, we have accelerated our most recent security patches and applied them to all affected currently supported products,” the post said.
“I think it is an abundance of caution, but in addition, some pro-active concern,” said security expert Edward Haletky, CEO of The Virtualization Practice LLC. While there is historical evidence that it is possible to crash a VM using paravirtualized drivers and backdoor elements in the past, he added, “the execution of code on the host is intrinsically difficult regardless of how an escape is performed.”
These aren’t the first VMware product patches which raise the spectre of rogue code executed on a host – even in the last few weeks. A security advisory was also issued without nearly as much fanfare April 12, in which three critical patches were released for VMware’s vShield Endpoint security product.
VMware’s Knowledge Base article paired with today’s security advisory also specifically credits an individual, Derek Soeder of Ridgeway Internet Security LLC, with identifying some of the vulnerabilities, rather than specifically linking their discovery back to the leaked file. Soeder, meanwhile, was publicly raising security issues with VMware’s software in a blog posted March 30, before the 2004 source code file was leaked.
Regardless of whether the hacker who threatens to leak megabytes more source code on May 5 acts on that threat, or whether these patches are specifically related to the high-profile leak, VMware customers shouldn’t take any chances, experts say.
“For now, all we can do is what we should always do, keep current on our patching levels,” said Christian Mohn, senior infrastructure consultant at EVRY Consulting in Norway.
Meanwhile, “May 5th might just turn into something more interesting than I had thought a week ago,” he said.