VMware response to GRUB2 security vulnerability CVE-2020-10713
Article ID: 317616
Updated On:
Products
VMware vCenter Server
Issue/Introduction
On July 29, 2020, a security vulnerability in GRUB2 identified by CVE-2020-10713 was disclosed. Exploitation of the issue allows bypassing Secure Boot on systems where Secure Boot is enabled. In order to exploit the issue, root or administrative access to the system is needed.
VMware has investigated the impact CVE-2020-10713 may have on VMware products.
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 Vulnerability
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 the vulnerability 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.
The vulnerability does not itself enable privileged access on the host or guest OS. Exploitation of the vulnerability in a virtual machine does not affect the host.
VMware has investigated the impact CVE-2020-10713 may have on VMware products.
Background
Secure BootThe 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 Vulnerability
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 the vulnerability 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.
The vulnerability does not itself enable privileged access on the host or guest OS. Exploitation of the vulnerability in a virtual machine does not affect the host.
Resolution
Remediation will require that:
Note (1): Secure Boot is not currently enabled in VMware Virtual Appliances.
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.
Note (2): To update dbx using an OS update, consult the OS vendor for availability and installation guidance.
When a host or guest is configured to use a Trusted Platform Module (TPM) to measure its boot process, exploitation of this issue will be observable through altered TPM measurements of the boot process.
Exploitation of the vulnerability requires 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 this issue is that the attacker is capable of establishing pre-OS persistence.
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.
- 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 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 and 3.0:
- Photon OS 1.0 - PHSA-2020-1.0-0311
- Photon OS 2.0 - PHSA-2020-2.0-0267
- Photon OS 3.0 - PHSA-2020-3.0-0120
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:
- Canonical: https://ubuntu.com/security/notices/USN-4432-1
- Debian: https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot
- Microsoft: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011
- Red Hat: https://access.redhat.com/security/vulnerabilities/grub2bootloader
- SUSE: https://www.suse.com/support/kb/doc/?id=000019673
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 this vulnerability poses no incremental risk.When a host or guest is configured to use a Trusted Platform Module (TPM) to measure its boot process, exploitation of this issue will be observable through altered TPM measurements of the boot process.
Exploitation of the vulnerability requires 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 this issue is that the attacker is capable of establishing pre-OS persistence.
Further Information
Can exploitation of this issue 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.
Feedback
Yes
No
Powered by
