Identify VMs that have VMware Tools with the OpenSSL v3 vulnerability

In OpenSSL version 3.0.0 to 3.0.6, a critical vulnerability is found (link). A lot of vendors use these versions of OpenSSL in their products. VMware has the following statement:

To date, no VMware products have been found to be critically impacted by CVE-2022-3602 or CVE-2022-3786. Regardless, VMware products that consume OpenSSL 3.0.x will consume 3.0.7 fixes as a precautionary measure in upcoming releases.

VMware Tools version 12.0.0 and 12.1.0 both contain the OpenSSL 3.0.x version.

VMware Tools OpenSSL version
12.0.0 3.0.0
12.1.0 3.0.3

To quickly identify what VMs have the OpenSSL 3 vulnerability present you can use PowerCLI. The following script identifies all VMware Tools 12 versions and higher:

$vcserver = 'the FQDN of the vCenter Server name'
Connect-VIServer $vcserver
Get-VM | Where-Object {$_.Guest.ToolsVersion -ge '12.0.0'} | Select -property Name,PowerState,@{Name='Toolsversion';Expression={$_.Guest.Toolsversion}} | Sort Toolsversion
Disconnect-VIServer * -Confirm:$false

The results can be exported to a CSV file by adding the following line after the Sort ToolsVersion

| export-csv c:\temp\vmwtools.csv -notypeinformation

OpenSSL v3.0.7 is released. This version will fix the critical vulnerability. The NCSC has a GitHub page (Link) with software that is affected. Now it is time for VMware to release an updated version of VMware Tools that included the new OpenSSL version

Update: November 29, 2022

VMware Tools 12.1.5 is released. This is a maintenance release of VMware Tools to provide fixes for critical product issues and security issues:

  • Updated OpenSSL to 3.0.7
  • Updated zlib to 1.2.12 with additional fixes
  • Updated GLib to 2.56.3 with additional fixes
  • Updated libxml2 to 2.10.2
  • This release resolves CVE-2022-31693. For more information on this vulnerability and its impact on VMware products, see https://www.vmware.com/security/advisories/VMSA-2022-0029.html.

The release notes can be found here and the download location can be found here.

 

Quick tip: VMware VCSA installer page is blank when selecting a datastore

While upgrading a vCenter Server 6.7 to version 7 Update 3 using the vCenter Server 7 UI installer, I was not able to select a datastore for installing the new vCenter Server Appliance (VCSA).

The datastore selection was blank as shown in the following image.

 

 

After googling I found the solution on a blog from another vExpert (link) who experience this issue with VCSA 6.5/6.7 installers. So the issue still exists in the vCenter Server 7 UI installer.

Here are the steps to solve this:

  • Go to the %appdata% folder (it opens the C:\Users\<username>\AppData\Roaming folder)
  • Delete the installer folder.
  • Run the VCSA installer again and you see the datastores again

Install Windows 11 on VMware vSphere with a virtual TPM

Yesterday I wrote a blog called “Install Windows 11 as VM on VMware vSphere / Workstation without TPM 2.0 chipset“. In this blog article, I explained how to install Windows 11 without having a TPM 2.0 chipset by using a registry hack. Paul Braren from tinkertry.com created a cool video (link) about installing Windows 11 on VMware vSphere using my blog article. Bob Plankers (@plankers) replied on Twitter that virtual TPM can be used too. 

So I did some research in my home lab. With VMware vSphere and VMware Workstation, it is possible to install Windows 11 by using a vTPM device that emulates a physical TPM 2.0 chipset without having one. This is called Virtual Trusted Platform Module (vTPM). A vTPM performs the same functions as a hardware TPM, it performs cryptographic coprocessor capabilities in software So without having a physical TPM 2.0 you can run Windows 11 without performing any hacks to the Windows 11 Operating System.

In this blog post, I explain how to configure vTPM for VMware vSphere and install Windows 11. Here are the steps:

Requirements for vTPM

  • EFI firmware
  • Hardware Version 14 or later
  • vSphere 6.7 or later
  • Virtual Machine encryption
  • Key Provider. The Key Provider is used to enable encrypted technologies such as TPM

To enable vTPM you must first add a Key Provider

  • Open the vSphere Client URL (https://vcentername/ui)
  • Log-in
  • Click on the vCenter name – Configure and select Key Providers
  • Click on ADD
  • Select Add Native Key Provider. When using the Native Key provider you don’t need an external key server.
  • Enter a name for the Key Provider and uncheck “Use key provider only with TPM protected ESXi hosts (Recommended).

  • Select Backup and uncheck “Protect Native Key Provider data with password (Recommended)” and click on BACK UP KEY PROVIDER

  • The Key Provider is configured and active now

 

Windows 11 VM Configuration

For the Windows 11 VM configuration, I configured the following:

  • Create or download a Windows 11 ISO (for more information see the blog post mentioned at the beginning).
  • Copy the ISO to a datastore that can be accessed  when used to install Windows 11

In the vCenter client create a new VM with the following specification:

  • Configuration step 1: Create a new Virtual Machine
  • Configuration step 2: Enter the Virtual Machine name
  • Configuration step 3: Select the ESXi host or cluster for the VM
  • Configuration step 4: Select the datastore and select Encrypt this virtual machine

  • Configuration step 5: Compatibility: ESXi 7.0 U2 and later (I’m using ESXi 7)

  • Configuration step 6: Guest OS: Guest OS Family: Windows
    • Guest OS Version: Windows 10 (64-bit)
    • Enable Windows Virtualization Based Security: Check

  • Configuration step 7: CPU: 2 or more
    • Memory: 4 GB or more
    • Hard disk: 64 GB or more
    • CD/DVD: Mount the ISO on the datastore
    • Custom Hardware Select Add New Device and choose for Trusted Platform Module

 

  • Configuration step 8: VM configuration overview
    • Click on Finish

  • Start the VM and the installation begins without complaining that this PC can’t run Windows 11

Windows 11 can be installed without having a physical TPM 2.0 chipset or using the registry hack mentioned at the beginning of the blog post. How cool is that!