VMware recently responded to the pwn2own security exploit against VMware Workstation. Patches have been released for ESXi, Fusion, and Workstation. VMware says they are not aware of the exploit being used in the wild.
Here’s VMware’s response:
The security advice boils down to following general best practices:
- Depth in defense
- Apply vendor patches
From the article:
As offensive security evolves, so does defensive security. With vSphere 6.5, VMware began deploying sandboxing technology around virtual machines to prevent a single arbitrary code execution from spreading across a host – a technique we have adapted from studying how web browsers and cell phones have evolved to defend against offensive security research. We are proactively disabling or removing legacy features – the loss in compatibility is increasingly outweighed by the reduction in attack surface. And we are investing deeply in ease-of-upgrade, recognizing that prompt security patches do little good if they cannot be deployed to production in time.
When VMware models threats, we consider three categories of actor. The “nation-state” actor has vast resources but generally employs them against limited targets; such an actor will find a way to breach security, whether by technical means or something simpler (money, ideology). The “professional” actor has more limited resources, and tends to look for the softest and most profitable target; defending against this actor amounts to staying on or ahead of the security research curve. And the “script kiddie” uses off-the-shelf resources and previously-known issues; defending here generally requires little more than staying up to date, and the biggest risk is installations which fail to deploy existing patches. The Pwn2Own competition shows that the difficulty of hypervisor attacks is moving from the “nation-state” category to the upper end of the “professional” category. This is a trend we have been expecting for a while, as security research tools become more powerful.
Be sure to prioritize security focus appropriately. Using low entropy passwords or allowing direct access to the management network are probably greater risks to your infrastructure security than more difficult to exploit issues such as this (YMMV and IMHO).