On February 15, 2022 VMware released VMSA-2022-0004, a critical advisory addressing security vulnerabilities found and resolved in VMware ESXi, Workstation, Fusion, and Cloud Foundation. These vulnerabilities are in the virtual USB/XHCI controllers found by default on many virtual machines, as well as the ESXi 7 sandbox (what is the sandbox? See below!). Exploitation of these vulnerabilities from a virtual machine would allow an attacker access to the hypervisor, so it is very important that you patch them soon.
As we have done in the past for major security advisories we are maintaining a large questions & answers document alongside the VMware Security Advisory itself. The link is below.
Things to Note About VMSA-2022-0004
vSphere customers who are also VMware Cloud on AWS customers will note that the issue has been proactively resolved in any deployed VMware Cloud on AWS SDDCs, as part of the shared responsibility model. No further action is needed by customers to protect workloads in those environments. Easy!
Customers who have fully updated to vSphere 7 Update 3c have the updates in place already. If you are already updating to that release, please keep going. 🙂
Customers who cannot upgrade to vSphere 7 Update 3c have options, too. One of the biggest things customers have told us about security updates is that it’s hard when they coincide with an Update release, because Update releases often trigger requalification or testing processes inside their organizations. To help with this, patches have been released for vSphere 7 Updates 1 and 2, too. We still strongly recommend coming up to vSphere 7 Update 3c because of all the other quality and feature improvements there, but you can make that choice independently, without the pressure of a security issue.
This affects vSphere 6.x, too. vSphere 6.5 and 6.7 have updates available that resolve this. This is a good time to remind everyone that vSphere 6.5 and 6.7 end their general support on October 15, 2022 – eight months from now. Update 3 is always the last feature release in a major vSphere version, which means it is a good time to think about upgrading to vSphere 7, and we have terrific resources to help plan those upgrades. Upgrades are also really smooth nowadays.
VMSA-2022-0004 is a VM Escape, where someone with administrator- or root-level access to a virtual machine with a USB/XHCI controller can compromise the underlying host itself. Patching is always our recommendation because it removes the vulnerabilities completely. However, one workaround is to remove the USB/XHCI controllers from virtual machines. Reducing & removing extra hardware is always a security recommendation of ours, and the VMSA-2022-0004 Questions & Answers document has some PowerCLI samples to help you audit and automate that work. You might not be able to do it to all your VMs but doing it to your template VMs would be a good start, and a step you can take today to improve security in your future.
At the beginning here I mentioned the “sandbox,” and you might have asked “what is that?” It’s a feature introduced in vSphere 7 that helps prevent “VM Escape” situations where an attacker could find their way out of a guest, through a driver or other means, and take control of the underlying hypervisor:
The sandbox only lets the VM Runtime, or VMX process (the VM process you’d see on an ESXi host if you logged in and used the “ps” command, like “ps | grep vmx”) do things that are preapproved. If the sandbox sees unapproved activity (system calls, etc.) it terminates the VMX process, which powers off the VM (a big hint something is going on). Is it perfect? Of course not — the issues with settingsd on ESXi 7 in this VMSA are issues with the sandbox itself. Regardless, it serves as a very effective form of defense-in-depth, helps preserve the deep isolation between workloads, and is one of the many little things in vSphere 7 that make ESXi a very secure platform overall.
