Boot Hole Vulnerability - GRUB 2 boot loader - CVE-2020-10713

Executive summary

Red Hat is currently responding to a flaw in the GRUB 2 boot loader that impacts our products, including Red Hat Enterprise Linux. This flaw allows an attacker, already on the system, to hijack the boot process and execute malicious code during system startup. Systems utilizing UEFI Secure Boot, which protect systems by verifying the software used to boot up a computer, can also be bypassed using this vulnerability. This issue is assigned CVE-2020-10713 and rated with a severity impact of Moderate. Red Hat customers using affected versions are recommended to apply updates. Red Hat also recommends updating to the most recent images and latest version of container host-systems.

The following Red Hat product versions are impacted:

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Atomic Host 

• OpenShift Container Platform 4 (RHEL CoreOS)

To determine if your system is currently vulnerable to these flaws, see the Diagnose section below. Additionally, customers can refer to the Ansible playbook for automatic remediation provided below.

Technical summary

In CVE-2020-10713, an attacker may use the GRUB 2 flaw to hijack and tamper the GRUB  verification process. This flaw also allows the bypass of Secure Boot protections. In order to load an untrusted or modified kernel, an attacker would first need to establish access to the system such as gaining physical access, obtain the ability to alter a pxe-boot network, or have remote access to a  networked system with root access. With this access, an attacker could then craft a string to cause a buffer overflow by injecting a malicious payload that leads to arbitrary code execution within GRUB. 

To ensure Secure Boot protections of the loaded kernel and prevent the system load of untrusted code at startup, newly validated keys and certificates are issued for grub2, kernel, fwupdate, fwupd, shim, and dbxtool packages.

Mitigation

There is no mitigation for the flaw. 

Remediation

Red Hat recommends all customers to update their grub2 packages. Red Hat customers using Secure Boot need to update kernel, fwupdate, fwupd, shim and dbxtool packages containing newly validated keys and certificates.

Users running Secure Boot with Red Hat Enterprise Linux 8 need to take additional steps to boot into previously released RHEL 8 kernels after applying the grub2 package updates. See the RHEL 8 section below for more details.

Technical details

The GRUB 2 boot loader is configurable via the grub.cfg file, which is composed of several string tokens. The configuration file is loaded and parsed at GRUB initialization right after the initial boot loader, called shim, has loaded it. During the parser stage, the configuration values are copied to internal buffers stored in memory. Configuration tokens that are longer in length than the internal buffer size end up leading to a buffer overflow issue. An attacker may leverage this flaw to execute arbitrary code, further hijacking the machine’s boot process and bypassing Secure Boot protection. Consequently, it is possible for unsigned binary code to be loaded, further jeopardizing the integrity of the system.

Background

What is UEFI Secure Boot and how it works?

Secure Boot is a UEFI firmware security feature developed by the UEFI Consortium that ensures only immutable and signed software are loaded during the boot time. Secure Boot leverages cryptography and digital signing to validate the authenticity, source, and integrity of the code that is loaded. These validation steps are taken to prevent malicious code from being loaded and to prevent attacks, such as the installation of certain types of rootkits. For more information on UEFI and Secure Boot see UEFI Secure Boot in Modern Computer Security Solutions. 

Trusted applications are signed by a central Certificate Authority. The public certificate is stored in the hardware, allowing third-party EFI applications signed by this certificate to load successfully.

On the Red Hat Enterprise Linux versions which support Secure Boot the signed and trusted application is the shim package which is the first application loaded by the machine’s firmware. The shim package itself holds Red Hat’s certificate and its own databases of trusted keys and code hashes that are allowed to be loaded. This data is used to verify the boot loader signature, which is GRUB 2, making sure it has not been compromised or tampered by a malicious actor. Once the verification succeeds, GRUB is loaded and verifies the kernel signature and confirms that it matches with Red Hat’s certificate or any hash enrolled by the user itself into the Allow DB. If there is a match, GRUB will load the kernel, which finishes the boot load process.

Product impact

Red Hat Enterprise Linux (RHEL) 7 and 8, Red Hat Enterprise Atomic Host, and RHEL CoreOS (part of Openshift Container Platform 4) ship the vulnerable GRUB 2 version. 

Red Hat Enterprise Linux 8

Due to hardening within the kernel, which is released as part of these updates, previous Red Hat Enterprise Linux 8 kernel versions have not been added to shim’s allow list. If you are running with Secure Boot enabled, and the user needs to boot to an older kernel version, its hash must be manually enrolled into the trust list. This is achieved by executing the following commands:

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign>

# reboot

Red Hat Enterprise Linux 7

Red Hat has added previous Red Hat Enterprise Linux 7 kernel hashes into the shim’s allow database, allowing Secure Boot users to boot into older versions of the kernel. 

RHEL Atomic Host

At this time, updating the shim binaries on RHEL Atomic Host is not possible. Customers should assess the issue and decide if provisioning nodes using updated boot media is warranted.

OpenShift Container Platform 4 (RHEL CoreOS)

At this time, Red Hat is not shipping updates for the EFI system partition (including shim, grub) for RHEL CoreOS. An accepted best practice is to reprovision nodes periodically; customers can do so using the updated “boot images.” Customers should assess their impact and decide if updating boot images at this time are warranted.

Since the vulnerability primarily affects the integrity of bare-metal systems with Secure Boot enabled, updating and using the new boot images is the only recommended action. The steps for updating boot images vary and are dependent on how customers have provisioned their bare-metal infrastructure. This process could require updating the PXE configuration of your boot infrastructure to provide new boot images, or it may involve reinstalling your bare-metal systems using an updated install ISO and bare-metal disk images. Customers should consider their environment and refer to OpenShift documentation on how to update the boot images correctly. For more information, see: Installing a cluster on bare metal. 

If reprovisioning nodes with updated boot images are required, customers should take the necessary steps to cordon and drain the nodes they wish to reprovision. Customers should reprovision their nodes one at a time to avoid disrupting the overall health of the cluster.

To cordon a node:

$ oc adm cordon <node name>

To drain a node:

$ oc adm drain <node name>

Once a node has been successfully cordoned and drained, customers should initiate a reboot and reinstallation of the node then confirm it was correctly reprovisioned with the updated boot images.

Updates for affected products

The shim package initially released has been replaced by a new version. Updated shim packages are available and can be used in conjunction with previously released grub2, fwupd, and fwupdate packages. For more information on the initial shim packages see https://access.redhat.com/solutions/5272311. Red Hat strongly recommends customers running affected versions apply available updates.

¹ What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?

² What is Advanced mission critical Update Support (AUS)?

³ What is the Red Hat Enterprise Linux SAP Solutions subscription?

⁴ Atomic Host

⁵ Advisory/Update link will be added once updates are live.

⁶ The shim package initially released has been replaced by a new version. Updated shim packages are available and can be used in conjunction with previously released grub2, fwupd, and fwupdate packages. For more information on the initial shim packages see https://access.redhat.com/solutions/5272311.

⁷ Updated dbxtool packages were released for RHEL 8 to address known bugs in functionality. Instructions for applying the DBX update can be found within the following article - How to update the Secure Boot Forbidden Signature Database (DBX) with the latest UEFI Revocation List file

Diagnose

The vulnerability detection script is intended for currently supported Red Hat Enterprise Linux versions. The detection script can also be used with layered products on top of Red Hat Enterprise Linux where customers have access to run the script.

Ansible Playbook

An Ansible playbook, CVE-2020-10713-update_fixit.yml, is provided below. This playbook updates all relevant packages. To use the playbook, specify the hosts you'd like to update with the HOSTS extra var:

ansible-playbook -e HOSTS=<myhosts> CVE-2020-10713-update_fixit--2020-07-29-1613.yml

To verify the legitimacy of the playbook, you can download the detached OpenPGP signature.

FAQ

Q: How do I check if my system has Secure Boot enabled?

A: It’s possible to check if Secure Boot feature is enable by running the following command:

    $ mokutil --sb-state

SecureBoot enabled

  NOTE: On systems with Secure Boot disabled, using the mokutil command with any variables will display the following output:  

# mokutil -l

EFI variables are not supported on this system

Q: Do I need to reboot or restart after installing updated packages?

A: Yes, a reboot is needed to ensure updated components are being used.

Q: How are containers impacted?

A: While this issue does not directly impact Red Hat Enterprise Linux-based containers, their security relies upon the integrity of the host kernel environment. Red Hat recommends updating to the most recent images and latest version of container host-systems. To protect the privacy of the containers in use, customers will need to apply and deploy the updates to the container host (such as Red Hat Enterprise Linux or Atomic Host). 

Q: I’m running Red Hat Enterprise Linux 7 and I’m not able to update my kernel version. Should I enroll the hash value from my kernel version into trusted DB?

A: It’s not needed. Older kernel versions for Red Hat Enterprise Linux 7 will be added automatically on the shim’s allow list.

Q: I’m running Red Hat Enterprise Linux 8, should I enroll the hash value from my kernel version into trusted DB?

A: Yes, older Red Hat Enterprise Linux 8 kernel versions won’t be trusted by default. To be able to boot any previous kernel version you can execute the following commands as root user:

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign command>

# reboot

Q: If I don’t use Secure Boot, can I continue to boot into previous versions of the RHEL 7 and 8 kernels without any changes after applying this update to GRUB? 

A: Yes, with Secure Boot option disabled no signature verification is performed thus previous kernel versions will still be bootable without any further required action.

Q: When will new DBX updates be applied into the UEFI firmware?

A: As a consequence of GRUB’s security flaw, the previous Red Hat Secure Boot signature will be revoked and placed into the Disallow DB (DBX) database, and a new signature will be used when customers apply the dbxtool update. A new DBX file is included in the update, that also contains the revocation for older Red Hat keys. However, the dbxupdate will not be performed by default and is targeted for IT professionals who want to exclude the older keys. A new, mandatory, and automatic dbxtool update will be released in the coming months to indefinitely revoke Red Hat keys for all Red Hat customers.  

Q: The vulnerability affects program code that runs independent of the use of Secure Boot. How then does the vulnerability’s impact differ between Secure Boot-enabled systems and other systems?

A: The Secure Boot mechanism is designed to allow only unmodified, trusted and signed code to be loaded by the machine’s firmware and subsequent loader components. This means Secure Boot imposes an extra security boundary that works as a mitigation for any attempts to load untrusted software during the boot stage (boot loader, kernel and kernel modules). Since the GRUB 2 flaw allows arbitrary code execution, an attacker can leverage this to bypass any signature checking or run untrusted code crossing the security boundary imposed by Secure Boot, thus jeopardizing the integrity of the kernel loaded. 

When Secure Boot is disabled no signature verification is performed; as a consequence there’s no additional security boundary to be crossed. Given this flaw allows any code to be loaded, this flaw for non-Secure Boot GRUB can be handled as any other flaw which allows arbitrary code execution.

Q: What should I do when the system hangs after POST and the grub menu never loads after applying the RHSA-2020:3216 or RHSA-2020:3217?

A: Refer to solution article, https://access.redhat.com/solutions/5272311. On Saturday August 1st 2020 Red Hat released updated shim packages which addressed this issue. It is strongly recommended that Red Hat customers do not use the older shim package released as part of RHSA-2020:3216 or RHSA-2020:3217 and instead use the shim package (or newer) released with RHBA-2020:3262 and RHBA-2020:3265.  

Acknowledgements

Red Hat thanks Jesse Michael and Mickey Shkatov from Eclypsium, for discovering and reporting this vulnerability. Red Hat also thanks Industry Partners and the GNU GRUB community for their collaboration on this issue. 

References

• Eclypsium - There's a Hole in the Boot 
• How to apply the updated DBX file within dbxtool updates
• Working with GRUB 2
• UEFI Secure Boot in Modern Computer Security Solutions
• How to use GPG to verify signed content form Product Security