Remediation will require that:
- Vulnerable bootloaders are replaced with updated versions, AND
- Hosts or virtual machines using UEFI Secure Boot receive a dbx update to ensure that the vulnerable bootloaders are no longer allowed to execute.
- Update vulnerable bootloaders
A vulnerable bootloader allows an attacker with privileged access to bypass Secure Boot. Update all vulnerable GRUB2 bootloaders to a fixed version. The following table lists the VMware products with a bootloader, and Photon OS and Virtual Machines.
Component containing bootloader | Affected | Action Required |
VMware ESXi | No | None |
VMware Virtual Appliances | No (1) | None |
VMware Photon OS 3, 4 when configured with UEFI Secure Boot | Yes | Update Photon OS (2) |
Virtual Machine guest OS, installation media and recovery media | Refer to OS vendor (3) (4) | Refer to OS vendor (3) (4) |
Note (1): Secure Boot is not currently enabled in VMware Virtual Appliances.
Note (2): The following Photon OS advisories document the grub2 update for Photon OS 1.0, 2.0, 3.0 and 4.0:
Note (3): Customers are advised to review the guidance put out by their OS vendors for addressing the issue on their Virtual Machines. The following list provides links to the advisories by several of these OS vendors
Note (4): Assessment should include all bootloaders, including those on OS installation media, on recovery or utility media, on network boot servers, and in existing virtual machines.
- Update the Secure Boot deny list
The Secure Boot deny list (dbx) should be updated to prevent vulnerable bootloaders from being used in future. The dbx update may be made available through an OS update or through a system firmware update. After evaluating the risks, consider deploying this update on all hosts and guests using Secure Boot.
IMPORTANT: Once the dbx update is applied to a system, any vulnerable bootloaders will no longer be allowed to boot on that system. To avoid rendering systems unbootable, ensure that each system's bootloader is updated before updating its dbx. It might be difficult or impossible to revert a dbx update.
IMPORTANT: On certain hardware systems, it is possible that installing a dbx update might cause a system malfunction. Confirm suitability with the system vendor before installing a dbx update.
Secure Boot Implementation | Action Required |
Host running VMware ESXi and booting with UEFI Secure Boot | - Confirm dbx suitability for host - Install the dbx update on the host (1) |
Virtual machine running on ESXi, Workstation or Fusion and configured with UEFI Secure Boot | - Confirm dbx suitability for the guest - Install the dbx update in the guest(2) |
Note (1): To update dbx using a system firmware update, consult the system vendor for availability and installation guidance.
Note (2): To update dbx using an OS update, consult the OS vendor for availability and installation guidance.
Mitigating factors
When a host or guest has not enabled Secure Boot or is using legacy BIOS, the security boundary provided by Secure Boot does not exist and therefore these vulnerabilities pose no incremental risk.
When a host or guest is configured to use a Trusted Platform Module (TPM) to measure its boot process, exploitation of these issues will be observable through altered TPM measurements of the boot process.
Exploitation of these vulnerabilities require root or system access on the host or guest OS. This level of privilege already allows for a full compromise of the OS. The additional gain from exploiting these issues is that the attacker is capable of establishing pre-OS persistence.
Further Information
Can exploitation of these issues inside a virtual machine cause compromise of the host?No.
Does the guest need to be updated before the host? Does the host need to be updated before the guest?The guest and host are independent and may be updated in any order.
Does installing an update on the host protect the guest?No. Updates need to be deployed on all affected hosts and guests.
Is the dbx update required in virtual machines (or physical machines) running a guest OS other than Linux?Yes. It may still be possible for an attacker to install a vulnerable GRUB2 bootloader and use it to compromise the boot of guest OSes other than Linux.
Note:- If you create a virtual machine with the setting "Compatible with: ESXi 8.0 and later" (vSphere client) or "Compatibility: ESXi 8.0 virtual machine" (ESXi host client), the VM will already have a dbx that includes the updates to block the vulnerable GRUB2 bootloaders discussed in this article. So you will not be able to install or boot a vulnerable version of Linux in such a VM unless you disable Secure Boot in the VM's settings.