Customers should be aware of an important issue with VMware Tools where a non-privileged user on a Windows VM could read information or cause problems in a VM running VMware Tools lower than 10.3.10. The official designation from VMware is VMSA-2019-0009 on the VMware Security Advisories page and mailing list. This vulnerability is classified as “important” which, according to the Security Response Policy, means that it can result “in the complete compromise of confidentiality and/or integrity of user data” but has to be exploited “through user assistance or by authenticated attackers.”
Put simply, you should examine and remediate any Windows VM with non-administrator users. A great example is Windows VMs running Microsoft Remote Desktop Services, but don’t limit your thinking to only user accounts. Any guest OS that has service accounts that support software, such as Microsoft SQL Server or IIS, is at risk; especially if the software isn’t completely up to date. Attackers could use flaws in unpatched software to execute other attacks on the guest OS, like this one.
While we strongly urge you to patch, only you and your organisation can assess the risk and business impact involved. There may be other compensating controls, such as vSphere Platinum with AppDefense in place as additional levels of protection.
How do I know if I am affected?
A great way to determine what VMs in your environment are affected is with PowerCLI. This command will show you all the VMs with Tools versions below 10.3.10 (which has build number 10346):
Get-VM | Get-View | Where-Object {$_.Config.Tools.ToolsVersion-lt‘10346’} | Sort-Object Name | Select Name | Format-Table
This will show you all the Windows VMs with Tools versions below 10.3.10:
Get-VM | Get-View | Where-Object {$_.Config.Tools.ToolsVersion-lt‘10346’ -and $_.Guest.GuestFamily -eq ‘windowsGuest’} | Sort-Object Name | Select Name | Format-Table
(Thanks to Brent Miller for pointing out the issues with just pulling Guest.ToolsVersion in the comments)
You can always check a VM manually from the vSphere Client’s Summary tab, too:
Note that Linux Guest OS running are unaffected, so you don’t need to worry if your repo for open-vm-tools is only providing 10.3.5.
How do I get new VMware Tools releases?
As you may know, the release cycles for VMware Tools and vSphere are not linked. VMware Tools releases more regularly, and if using Tools bundled with ESXi releases you may find yourself behind the curve. The latest release of ESXi available at time of writing is 6.7 Update 2a, bundled with VMware Tools 10.3.5. Note that while this vulnerability only exists in 10.2.x and 10.3.x versions of VMware Tools (10.0.12 and 10.1.x are unaffected) it’s generally recommended that you should look to upgrade where possible. The above PowerCLI will show *all* versions below the latest.
If you download the “VMware Tools Offline VIB Bundle” you can leverage vSphere Update Manager (VUM) to deploy the new installers to your hosts without downtime. Import the VIB into VUM and attach it to a baseline, or check to make sure it is included when using the default baselines. Since vSphere 6.5 the host is polled for a new version of VMware Tools every 5 minutes. As such you should start to see the guest alerts for a new version of VMware Tools quickly. This is checked on a power operation on older versions (power on/power off). However the easiest way to do this is to vMotion to another host, as vMotion constitutes a power operation.
Larger environments may prefer to keep a single copy of the latest versions of the installers in a centralised location. We have information on vSphere Central which walks you through how to do this. vSphere 6.7U1 released a new API to allow this to be configured without requiring maintenance mode or reboots. This was detailed on in our vSphere Blog post “Configuring a VMware Tools Repository in vSphere 6.7U1.”
If you use a version of ESXi that ships with VMware Tools a new version of Tools will ship with the next patch update to ESXi. Depending on your own assessments of risk you may want to address this proactively. It might also be worth starting to manage the VMware Tools separately from ESXi. This would be something to discuss with your downstream guest OS administrators if that isn’t you.
How do I install new VMware Tools versions?
Just as with reporting, it is also very easy to initiate a VMware Tools update with PowerCLI:
One thing to consider when pushing upgrades to VMware Tools is that the upgrade process may require that you reboot your guest OS. If a reboot will be required depends on which version of VMware Tools upgrading from, as well as which components you have installed. For testing, keep in mind that the “Get-VM” cmdlet can take an individual VM name, and you can also prepend the “Get-Folder” PowerCLI cmdlet if you want to test on a folder of VMs:
You can always initiate a Tools upgrade from the vSphere Client, too:
If you select the “Automatic Upgrade” option above this will automatically reboot your VM if needed when the upgrade completes. Clearly this isn’t going to be a great idea in all cases!
Thankfully we have some advanced options that can be added to the installer which will prevent the reboot – these are detailed in KB1018377. Be aware that using these advanced options will perform the upgrade, however you’re still running the older version until reboot. This places your OS in a “pending reboot” state, which may prevent other applications and updates installing until reboot. Be sure to think about this and plan your upgrades accordingly.
Another option that we have is to set an option in the settings for the virtual machine itself:
As you might expect, this will upgrade VMware Tools the next time the VM powers on. This can make a lot of sense, but bear in mind that you might not have control over when that machine restarts. A BSOD, or the guest admin can cause a restart at a time you don’t expect, and if that’s the case you then must wait for your upgrade to complete before the VM is fully running again.
Guest OS Admin Control
While we’re talking about guest OS administrators, note that there is an advanced option setting on your VMs which will prevent your VI admins from managing VMware Tools. Maybe you have a mission critical database server. The guest admins want full control over what is installed, when things are upgraded, and — most importantly — when the OS is restarted. You do this by adding the advanced configuration option onto the configuration of the VM. This process is detailed in KB2007298. With this configured your guest admins will see a systray message when an upgrade of VMware Tools is available. Alternately, they can check for and perform upgrades by doing the following from the CLI:
VMwareToolboxCmd.exe –v Checks version installed
VMwareToolboxCmd.exe upgrade status Checks for available upgrades
VMwareToolboxCmd.exe upgrade start Starts the upgrade process. You will see the installer GUI installer pop up, but this is an automated install that requires no interaction.
In Conclusion
VMware Tools are an important part of the VMware product suite, but they are a piece of software just like the rest of our IT ecosystems that needs attention & updates from time to time, not just for new functionality but also to resolve problems. Taking time to explore and test the options for managing Tools is an investment in your organisation’s security and stability. Security is everybody’s concern in IT, and cooperation is essential to ensure that there aren’t gaps or cracks that an attacker can slip through.
Please sign up for the VMware Security Advisories mailing list if you haven’t already. This ensures that you get proactive notifications whenever there is an issue found. Thank you!
(Thanks to Bob Plankers for contributions to this post)
