VMware response to GRUB2 security vulnerabilities CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418

Products

• VMware vSphere ESXi

Issue/Introduction

On March 2, 2021, multiple security vulnerabilities in GRUB2 identified by CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233 and CVE-2021-3418 were disclosed. Exploitation of these issues allows bypassing Secure Boot on systems where Secure Boot is enabled. In order to exploit these issues, root or administrative access to the system is needed.

VMware has investigated the impact these CVEs may have on VMware products.

Note: These CVEs are a follow-up to CVE-2020-10713 which was disclosed in July 2020, see VMware Knowledge Base Article 80181. After this disclosure, independent security researchers and core GRUB contributors have reviewed grub2 for security correctness leading to the CVEs disclosed on March 2, 2021.
 

Background

Secure Boot
The aim of Secure Boot is to ensure that the entire chain of executable code from the system firmware through to the operating system is known and trusted, with each component in that chain verifying the integrity of the next.

Secure Boot uses digital signatures to ensure that only known and trusted code is executed by the system firmware before the operating system is launched.  Secure Boot is controlled by two databases: The allow list (db) contains a list of allowed digital signatures (typically in the form of X.509 certificates of signing authorities), and the deny list (dbx) contains a list of prohibited digital signatures (typically in the form of SHA-256 Authenticode hashes of specific executable images).  For code to be executed, it must be approved by db and must not be specifically prohibited by dbx.

Scope of the Vulnerabilities
Vulnerable versions of GRUB2 may be used to bypass Secure Boot protection, which breaks the chain of trust by allowing malicious software to execute before the operating system has loaded.

Exploitation of these vulnerabilities requires privileged access on the host or guest OS. If successful, it would allow an attacker to establish pre-OS persistence on that host or guest only.

These vulnerabilities do not itself enable privileged access on the host or guest OS.  Exploitation of these vulnerabilities in a virtual machine does not affect the host.

Environment

VMware vSphere ESXi 8.0.0

Resolution

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.

1. 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:

• Photon OS 1.0 - Not relevant as Secure Boot is not supported on Photon OS 1.0
• Photon OS 2.0 - Not relevant as Secure Boot is not supported on Photon OS 2.0
• Photon OS 3.0 - https://github.com/vmware/photon/wiki/Security-Updates-3.0-202
• Photon OS 4.0 - https://github.com/vmware/photon/wiki/Security-Updates-4.0-1

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

• Debian: https://www.debian.org/security/2021-GRUB-UEFI-SecureBoot
• Redhat: https://access.redhat.com/security/vulnerabilities/RHSB-2021-003
• SUSE: https://www.suse.com/support/kb/doc/?id=000019892
• Ubuntu: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021

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.

2. 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.