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

Public Date:
Updated -
Status
Ongoing
Impact
Moderate

Insights vulnerability analysis

View exposed systems

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

Secure Boot is split into several pieces and stages. The first important concept is the Allow DB (DB) and Disallow DB (DBX) databases. The Allow DB (DB) database stores the hashes and keys for trusted loaders and EFI applications that are allowed to be loaded by the machine’s firmware. The Disallow DB (DBX) database stores revoked, compromised, and non-trusted hashes and keys. Any attempt to load signed code using the Disallow DB keys or in the case where the hash matches a Disallow DB entry will lead to boot failure. 

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.

Product

Package

Advisory/Update

Red Hat Enterprise Linux 8 

grub2, shim, fwupd

RHSA-2020:32166

Red Hat Enterprise Linux 8shimRHBA-2020:32626

Red Hat Enterprise Linux 8

kernel

RHSA-2020:3218

Red Hat Enterprise Linux 8

kernel-rt

RHSA-2020:3219

Red Hat Enterprise Linux 8

dbxtool

Update pending5

Red Hat Enterprise Linux 8.1.0 Extended Update Support1

grub2, shim, fwupd

RHSA-2020:32236

Red Hat Enterprise Linux 8.1.0 Extended Update Support1

shimRHBA-2020:32636

Red Hat Enterprise Linux 8.1.0 Extended Update Support1

kernel

RHSA-2020:3222

Red Hat Enterprise Linux 8.1.0 Extended Update Support1

dbxtool

Update pending5

Red Hat Enterprise Linux 8.0.0 Update Services for SAP Solutions2,3

grub2, shim, fwupd

RHSA-2020:32276

Red Hat Enterprise Linux 8.0.0 Update Services for SAP Solutions2,3

shimRHBA-2020:32646

Red Hat Enterprise Linux 8.0.0 Update Services for SAP Solutions2,3

kernel

RHSA-2020:3228

Red Hat Enterprise Linux 8.0.0 Update Services for SAP Solutions2,3

dbxtool

Update pending5

Red Hat Enterprise Linux 7

grub2, shim, fwupdate

RHSA-2020:32176

Red Hat Enterprise Linux 7shimRHBA-2020:32656

Red Hat Enterprise Linux 7

kernel

RHSA-2020:3220

Red Hat Enterprise Linux 7

kernel-rt

RHSA-2020:3221

Red Hat Enterprise Linux 7

dbxtool

Update pending5

Red Hat Enterprise Linux 7.7 Extended Update Support1

grub2, shim, fwupdate

RHSA-2020:3274

Red Hat Enterprise Linux 7.7 Extended Update Support1

kernel

RHSA-2020:3224

Red Hat Enterprise Linux 7.7 Extended Update Support1

dbxtool

Update pending5

Red Hat Enterprise Linux 7.6 Extended Update Support1

grub2, shim, fwupdate

RHSA-2020:3271

Red Hat Enterprise Linux 7.6 Extended Update Support1

kernel

RHSA-2020:3226

Red Hat Enterprise Linux 7.6 Extended Update Support1

dbxtool

Update pending5

Red Hat Enterprise Linux 7.4 Update Services for SAP Solutions, Advanced Update Support2,3

grub2, shim, fwupdate

RHSA-2020:3275

Red Hat Enterprise Linux 7.4 Update Services for SAP Solutions, Advanced Update Support2,3

kernel

RHSA-2020:3230

Red Hat Enterprise Linux 7.4 Update Services for SAP Solutions, Advanced Update Support2,3

dbxtool

Update pending5

Red Hat Enterprise Linux 7.3 Update Services for SAP Solutions, Advanced Update Support2,3

grub2, shim

RHSA-2020:3276

Red Hat Enterprise Linux 7.3 Update Services for SAP Solutions, Advanced Update Support2,3

kernel

RHBA-2020:3231

Red Hat Enterprise Linux 7.3 Update Services for SAP Solutions, Advanced Update Support2,3

dbxtool

Update pending5

Red Hat Enterprise Linux 7.2 Advanced Update Support2,3

grub2, shim

RHSA-2020:3273

Red Hat Enterprise Linux 7.2 Advanced Update Support2,3

kernel

RHSA-2020:3232

Red Hat Enterprise Linux 7.2 Advanced Update Support2,3

dbxtool

Update pending5

RHEL Atomic Host4

Image

August 11, 2020

OpenShift Container Platform 4 (RHEL CoreOS)

Image 

August 20, 2020

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

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

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

4 Atomic Host

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

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

Diagnose

A vulnerability detection script has been developed to determine if your system is currently vulnerable to this flaw. To verify the authenticity of the script, download the detached OpenPGP signature.

    Determine if your system is vulnerable

    Version 1.1

    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.

    Automate the update

    Version 1.1

    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

    Subscriber exclusive content

    A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

    Current Customers and Partners

    Log in for full access

    Log In

    9 Comments

    Subscriber exclusive content

    A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

    Current Customers and Partners

    Log in for full access

    Log In

    Will you also respin the install media for RHEL versions that are still in use? For example 7.6 for SAP?

    Klaas, I don't see the reason to respin the install media, as the update isn't included in the install media. It only comes via ERRATA update. Does this answer your question?

    I thought they will need to have a new shim version because the key used to sign it on the boot media will be revoked (or at least that was my understanding)

    OK, now I got it, but I'm not sure if the key will be revoked or not. Anyway. Well, usually we do not recreate installation-media. Not sure in this specific case, but I think as a workaround installing without secure boot enabled, upgrading to the latest packages and afterwards enable secure boot again, should work, isn't it?

    I would guess so, hopefully I won't have to reinstall any "old" systems ;)

    The >older< systems shouldn't be an issue, they don't have EFI, right? :-)

    My question as well. We boot in legacy BIOS mode, so this doesn't apply at all? Detection scripts says our grub2 packages are vulnerable, but I think that would be the case only if we booted UEFI.

    Hello Bret,

    There are two different points here. The vulnerability exists in the grub2 package independently on using EFI or Legacy BIOS systems. For legacy BIOS system you can handle that based on your risk analysis and your need to update or not the system, however the shim update is not mandatory as no signature verification is performed. You can find more details about that in the FAQ sections. Older kernels, bios and ISOS will continue to boot normally in BIOS systems as it doesn't have the concept of allowed or disallowed databases as consequence of not supporting Secure Boot.

    I have no information currently available. While the new DBX update is not enforced old ISOs will continue to boot successfully.