You'll recall that speculative execution, a feature of modern microprocessors, was recently identified as exploitable in such as way as to leak memory from a system. And to make matters worse, it's possible to leak memory between VMs and between VMs and their hosts. While currently demonstrated techniques require local admin access, it's certainly possible to use other attack vectors to get root, then attack the processor. Good times.
VMware was quick to respond to the threat by issuing several security advisories, but most importantly this one: VMSA-2018-0004. vSphere admins everywhere began the routine process of deploying patches to their hosts, updating vCenter, and making sure that all VMs were running hardware version 9 or later.
But over the weekend, VMware made a minor edit to this security advisory. And by minor, I mean a huge update that should make you put the brakes on remediation efforts. From the updated KB, here's the important bit:
Intel has notified VMware of recent sightings that may affect some of the initial microcode patches that provide the speculative execution control mechanism for a number of Intel Haswell and Broadwell processors. The issue can occur when the speculative execution control is actually used within a virtual machine by a patched OS.You're probably wondering what the hell a "sighting" is after reading this. Short version: it's what Intel calls an issue with a processor that has been reported not just in their internal testing, but in a customer environment in the field. In other words, this is not a theoretical issue. It's an observed fact.
Of course, the VMware KB is lacking in details on what effect this issue has on running virtual machines. If VMware is taking the bold step of removing the speculative execution protection patches from the VUM download source, I'll assume the effect is bad. We're doing some testing to determine what exactly happens when a guest OS attempts to use the protections provided by these VMware patches. I'll update the post with the results of our testing.
To VMware's credit, they're reacting to these security events as quickly as possible, and they're being transparent about their progress.
So in the meantime, if you've already deployed the update to your hosts (and your hosts have CPUs listed in the KB, which appears to list most CPUs in use today), you'll want to follow the instructions in the KB to implement corrective action to each host. Just do yourself a favor: carefully read the bullets following the config change. The devil is in the details.