GRUB2 UEFI SecureBoot Vulnerability: 'BootHole'

GRUB2 UEFI SecureBoot vulnerability - 'BootHole'

Developers in Debian and elsewhere in the Linux community have recently become aware of a severe problem in the GRUB2 bootloader that allows a bad actor to completely circumvent UEFI Secure Boot. The full details of the problem are described in Debian Security Advisory 4735 . The aim of this document is to explain the consequences of this security vulnerability, and what steps have been taken to address it.

• Background: What is UEFI Secure Boot?
• Multiple GRUB2 bugs found
• Key revocations needed to fix the Secure Boot chain
• What are the effects of key revocation?
• Debian 10.5 ( buster ) point release, updated installation and live media

Background: What is UEFI Secure Boot?

UEFI Secure Boot (SB) is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded.

SB works using cryptographic checksums and signatures. Each program that is loaded by the firmware includes a signature and a checksum, and before allowing execution the firmware will verify that the program is trusted by validating the checksum and the signature. When SB is enabled on a system, any attempt to execute an untrusted program will not be allowed. This stops unexpected / unauthorised code from running in the UEFI environment.

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means the firmware on these systems will trust binaries that are signed by Microsoft. Most modern systems will ship with SB enabled - they will not run any unsigned code by default, but it is possible to change the firmware configuration to either disable SB or to enrol extra signing keys.

Debian, like many other Linux-based operating systems, uses a program called shim to extend that trust from the firmware to the other programs that we need to be secured during early boot: the GRUB2 bootloader, the Linux kernel and firmware update tools (fwupd and fwupdate).

Multiple GRUB2 bugs found

Unfortunately, a serious bug has been found in the GRUB2 bootloader code which reads and parses its configuration (grub.cfg). This bug breaks the chain of trust; by exploiting this bug, it is possible to break out of the secured environment and load non-signed programs during early boot. This vulnerability was discovered by researchers at Eclypsium and given the name BootHole .

Instead of just fixing that one bug, developers have been prompted to do an in-depth audit of GRUB2's source code. It would have been irresponsible to fix one major flaw without also looking for others! A team of engineers have worked together for several weeks to identify and repair a range of further issues. We have found a few places where internal memory allocations could overflow given unexpected inputs, several more places where integer overflow in math calculations could cause trouble, and a few places where memory might be used after freeing it. Fixes for all of these have been shared and tested across the community.

Again, see Debian Security Advisory 4735 for a full list of the issues found.

Linux bugs found too

While discussing the GRUB2 flaws, developers also spoke about cases where Linux might also allow Secure Boot bypass. Two bugs were identified there, both allowing root to replace ACPI tables on a locked-down system when this should not be permitted. Fixes have already been released for those issues.

Key revocations needed to fix the Secure Boot chain

Debian and other operating system providers will obviously bereleasing fixed versionsof GRUB2 and Linux. However, that cannot be a complete fix for the problems seen here. Malicious actors would still be able to use older vulnerable versions of each to be able to work around Secure Boot.

To stop that, the next step will be for Microsoft to blacklist those insecure binaries to stop them being run under SB. This is achieved using the DBX list, a feature of the UEFI Secure Boot design. All of the Linux distributions shipping with Microsoft-signed copies of shim have been asked to provide details of the binaries or keys involved to facilitate this process. The UEFI revocation list file will be updated to include that information. At some future point, systems will start to use that updated list and will refuse to run the vulnerable binaries under Secure Boot.

The exact timeline for that change being deployed is not yet clear. BIOS/UEFI vendors will include the new revocation list in new firmware builds for new hardware at some point. Microsoft may also issue updates to existing systems via Windows Update. Some Linux distributions may issue updates via their own security updates process. Debian does not yet do this, but we are looking into it for the future.

What are the effects of key revocation?

Most vendors are wary about automatically applying updates which revoke keys used for Secure Boot. Existing SB-enabled software installations may suddenly refuse to boot altogether, unless the user is careful to also install all the needed software updates as well. Dual-boot Windows/Linux systems may suddenly stop booting Linux. Old installation and live media will of course also fail to boot, potentially making it harder to recover systems.

There are two obvious ways to fix a non-booting system like this:

• Reboot into rescue mode usingnewer installation media, and apply the needed updates that way; or
• Temporarily disable Secure Boot to regain access to the system, apply updates then re-enable it.

These may both sound like simple options, but each could be very time-consuming for users with multiple systems. Also be aware that enabling or disabling Secure Boot needs direct machine access, by design. It is normally not possible to change that configuration outside of the computer's firmware setup. Remote server machines may need special care here for exactly this reason.

For these reasons, it is strongly recommended that all Debian users be careful to install all thefor their systems as soon as possible, to reduce the chances of problems in future.

Updated packages

Note: Systems running Debian 9 ( stretch ) and older will not necessarily receive updates here, as Debian 10 ( buster ) was the first Debian release to include support for UEFI Secure Boot.

The signed versions of all packages here have been updated, even if no other changes were needed. Debian has had to generate a new signing key/certificate for its own Secure Boot packages. The old certificate was labelled Debian Secure Boot Signer (fingerprint f156d24f5d4e775da0e6a9111f074cfce701939d688c64dba093f97753434f2c ); the new certificate is Debian Secure Boot Signer 2020 ( 3a91a54f9f46a720fe5bbd2390538ba557da0c2ed5286f5351fe04fff254ec31 ).

There are five source packages in Debian that will be updated due to the UEFI Secure Boot changes described here:

1. GRUB2

Updated versions of Debian's GRUB2 packages are available now via the debian-security archive for the stable Debian 10 release ( buster ). Fixed versions will be in the normal Debian archive for development versions of Debian (unstable and testing) very soon.

2. Linux

Updated versions of Debian's linux packages are available now via buster-proposed-updates for the stable Debian 10 ( buster ) release and will be included with the upcoming 10.5 point release. New packages are also in the Debian archive for development versions of Debian (unstable and testing). We hope to have fixed packages uploaded for buster-backports soon also.

3. Shim

Due to the way that Debian's Secure Boot key management works, Debian does not need to revoke its existing Microsoft-signed shim packages. However, the signed versions of the shim-helper packages needed rebuilding to use the new signing key.

Updated versions of Debian's shim packages are available now via buster-proposed-updates for the stable Debian 10 ( buster ) release and will be included with the upcoming 10.5 point release. New packages are also in the Debian archive for development versions of Debian (unstable and testing).

4. Fwupdate

Updated versions of Debian's fwupdate packages are available now via buster-proposed-updates for the stable Debian 10 ( buster ) release and will be included with the upcoming 10.5 point release. fwupdate had already been removed from unstable and testing a while ago in favour of fwupd.

5. Fwupd

Updated versions of Debian's fwupd packages are available now via buster-proposed-updates for the stable Debian 10 ( buster ) release and will be included with the upcoming 10.5 point release. New packages are also in the Debian archive for development versions of Debian (unstable and testing).

Debian 10.5 ( buster ) point release, updated installation and live media

All of the fixes described here are targeted for inclusion in the Debian 10.5 ( buster ) point release, due for release on 1st August 2020. 10.5 would therefore be a good choice for users looking for Debian installation and live media. Earlier images may not work with Secure Boot in future as revocations roll out.

More information

Much more information about Debian's UEFI Secure Boot setup is in the Debian wiki - see https://wiki.debian.org/SecureBoot .

Other resources on this topic include:

• Eclypsium "BootHole" article describing the weaknesses found
• Microsoft Guidance for Addressing Security Feature Bypass in GRUB
• Ubuntu KnowledgeBase article
• Red Hat vulnerability article
• SUSE vulnerability article