RHSB-2021-003 ACPI Secure Boot vulnerability - GRUB 2 - (CVE-2020-14372)

^{​​​​​​​}Executive summary

Red Hat is aware of a flaw in the GRUB 2 boot loader that impacts our products, including Red Hat Enterprise Linux (RHEL). This flaw allows an attacker, already on the system, to bypass Secure Boot protections to load unsigned kernel modules. This vulnerability only affects systems utilizing UEFI Secure Boot, which is intended to protect systems by verifying the software used to boot up a system. This issue has been assigned CVE-2020-14372 and has been rated with a severity impact of Moderate. Red Hat customers using affected versions are recommended to apply updates. 

The following Red Hat product versions and containers are either directly affected or potentially impacted:

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Enterprise Atomic Host

• Red Hat OpenShift Container Platform 4 ^[1]
  

^[1] These products contain content from Red Hat Enterprise Linux (RHEL) and will release advisories with updated content soon after advisories are released for RHEL.

• Product containers that use the Red Hat Enterprise Linux base image. Base images will be updated to include fixes for this flaw, please ensure containers are current. The Container Health Index, part of the Red Hat Container Catalog, can be used to verify the security status of Red Hat containers.

• Products that pull packages from the RHEL channel. Please ensure that the underlying Red Hat Enterprise Linux package is current in these product environments.

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

Technical summary

In CVE-2020-14372, an attacker may use the GRUB 2 flaw to bypass the Secure Boot mechanism once the Linux kernel is loaded. The attacker can leverage the flaw by instructing grub (via its configuration file) after a reboot to load a custom Advanced Configuration and Power Interface (ACPI) table which disables the kernel's lockdown mechanism further allowing unsigned code to be loaded into kernel space, possibly compromising the system’s data integrity, confidentiality, and availability.

It should be noted that this impacts only environments using Secure Boot, and requires elevated privileges. An attacker will need to have already gained either physical control or root-level privileges to use this vulnerability. 

NOTE: A shim update will be released when ready, which includes the introduction of SBAT technology (see the background section for more information on SBAT) . This is to ensure that the shim updates are properly tested before release and to avoid introducing bugs into the boot system.

Mitigation

There is no mitigation available for this vulnerability.

Technical details

The GRUB 2 boot loader supports several modules and commands, which can be used to modify the boot loader behavior or extend its functionality. When the system is booted using Secure Boot technology, all load modules should comply and refuse to allow the user to load unsigned code. This vulnerability allows the GRUB 2 ACPI command option to not honor Secure Boot restrictions. This issue allows a malicious agent to load crafted ACPI tables, which can modify the environment, leading to Secure Boot circumvention.

An attacker with local root privileges can place a Secondary System Description Table (SSDT) onto the system and modify the grub configuration file to make it load the malicious SSDT. The crafted ACPI table is then run by the kernel, overwriting the kernel lockdown variable thus enabling the attacker to load unsigned kernel modules and kexec unsigned code. 

This event will require the shim’s hashes to be revoked. A new technology, called Secure Boot Advanced Targeting (SBAT), is being prepared to be released in the upcoming weeks, within the shim package as part of this disclosure. This will replace the functionality that was previously handled by the dbxtool package for this process. See the Background section below for more details. 

For more information on ACPI and SSDT, please see the References section at the bottom of this article. 

CVE-2020-14372

A flaw was found in GRUB 2, where it incorrectly enables the usage of the ACPI command when Secure Boot is enabled. This flaw allows an attacker with privileged access to craft a Secondary System Description Table (SSDT) containing code to overwrite the Linux kernel lockdown variable content directly into memory. The table is further loaded and executed by the kernel, defeating its Secure Boot lockdown and allowing the attacker to load unsigned code. The highest threat from this vulnerability is to data confidentiality and integrity, as well as system availability. 

On March 2, 2021, six other GRUB 2 issues, all Moderate severity, were also made public. Check the related CVE pages for more details.

• CVE-2020-25632 grub2: use-after-free in rmmod command

• CVE-2020-25647 grub2: out-of-bound write in grub_usb_device_initialize()

• CVE-2020-27749 grub2: Stack buffer overflow in grub_parser_split_cmdline

• CVE-2020-27779 grub2: cutmem command allows privileged user to remove memory regions when Secure Boot is enabled

• CVE-2021-20225 grub2: heap out-of-bounds write in short form option parser

• CVE-2021-20233 grub2: heap out-of-bound write due to mis-calculation of space required for quoting

Background

For more information about Secure Boot and how it works, refer to the What is UEFI Secure Boot and how it works? article.

The BootHole event in mid-2020 required a massive revocation of existing signed binaries and certificates rotation, causing a disruption on the shim and grub updates, as well as a big increase in DBX space consumption. 

As a result, enhancements to the UEFI revocation mechanism were required as the components involved in the boot path can evolve quicker and easier than UEFI firmware. The introduction of a new Generation-Based Revocation mechanism known as the UEFI Secure Boot Advanced Targeting (SBAT) model, will be released in the upcoming weeks as part of this disclosure within the shim package. This mechanism provides the ability to target easier revocation of compromised boot chain components. 

SBAT development was a collaboration by the Linux community and Microsoft, and consists of adopting new metadata in all of the UEFI binaries, to ship information about the vendor, product family, product, component, version, and generation. This metadata is digitally signed and can be further incorporated into the allow or deny list from the UEFI Secure Boot mechanism. 

This leverages future revocation events as boot chain tools will contain global generation numbers, thus making it possible to replace several hash or signature entries by only specifying a single metadata entry into the revocation list. 

For more technical insight regarding SBAT, refer to the “UEFI shim bootloader secure boot life-cycle improvements” document.

With the change to the SBAT mechanism, Red Hat will not need to rotate the Secure Boot keys and resign all trusted components (packages: kernel, shim, grub2, and fwupd) as the current key will be kept active and allowed to boot.

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. 

Updates for affected products

Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as errata are available.

[1] Advisory/Update link will be added once updates are live.

[2] What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?

[3] What is Advanced mission critical Update Support (AUS)?

[4] What is the Red Hat Enterprise Linux SAP Solutions subscription?

[5] An active Extended Life-cycle Support (ELS) subscription is required for access to this patch. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

[6] Product containers which use the Red Hat Enterprise Linux base image. Base images will be updated to include fixes for this flaw, please ensure containers are current. The Container Health Index, part of the Red Hat Container Catalog, can be used to verify the security status of Red Hat containers.

[7] Affected Red Hat CoreOS components consume RHEL content, and will be rebuilt and released as an advisory for the Red Hat OpenShift Container Platform.

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, you can download the detached OpenPGP signature as well. Instructions on how to use GPG signatures for verification are available on the Customer Portal.

Ansible Playbook

Additionally, an Ansible playbook is provided below. This playbook updates all relevant packages To use the playbook, specify the hosts you would like to update with the HOSTS extra var:

ansible-playbook -e HOSTS=<myhosts> CVE-2020-14372-update_fixit.yml

To verify the legitimacy of the playbook, you can download the detached OpenPGP signature as well. Instructions on how to use GPG signatures for verification are available on the Customer Portal.

Acknowledgements

Red Hat thanks Máté Kukri, for discovering and reporting this vulnerability. Red Hat also thanks Industry Partners and the GNU GRUB community for their collaboration on this issue.

References

How to use GPG to verify signed content from Product Security 

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

GRUB’s ACPI Command line usage

​​​​​​​Using SSDT Overlays within ACPI