GRUB2 UEFI SecureBoot vulnerabilities - 2021

Since the "BootHole" group of bugs announced in GRUB2 in July 2020, security researchers and developers in Debian and elsewhere have continued to look for further issues that might allow for circumvention of UEFI Secure Boot. Several more have been found. See Debian Security Advisory 4867-1 for more complete details. 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?

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

A bug has been found in the GRUB2 acpi module. This module is designed to provide a driver interface to ACPI ("Advanced Configuration and Power Interface"), a very common part of modern computing hardware. Unfortunately, the ACPI module also currently allows a privileged user to load crafted ACPI tables under Secure Boot and make arbitrary changes to system state; this allows people to easily break the Secure Boot chain. This security hole has now been fixed.

As with BootHole, instead of just fixing that one bug, developers have continued with more in-depth auditing and analysis of GRUB2's source code. It would have been irresponsible to fix one major flaw without also looking for others! We have found a few more places where internal memory allocations could overflow given unexpected inputs, 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 4867-1 for a full list of the issues found.

Key revocations needed to fix the Secure Boot chain

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

To stop that, the next step will be for Microsoft to block 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:

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 the recommended updates for their systems as soon as possible, to reduce the chances of problems in future.

Updated packages and keys

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.

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 will be available shortly via buster-proposed-updates for the stable Debian 10 (buster) release and will be included with the upcoming 10.10 point release. New packages will soon be in the Debian archive for development versions of Debian (unstable and testing). We hope to have updated packages uploaded for buster-backports soon also.

3. Shim and SBAT

The "BootHole" bug series was the first time that large-scale key revocation was needed in the UEFI Secure Boot ecosystem. It demonstrated an unfortunate design flaw in SB revocation: with lots of different Linux distributions and lots of UEFI binaries, the revocation list size grows quickly. Many computer systems only have a limited amount of space for storing key revocation data, and this could fill quickly and leave those system broken in various ways.

To combat this problem, the shim developers have devised a much more space-efficient method for blocking insecure UEFI binaries in the future. It is called SBAT (Secure Boot Advanced Targeting). It works by tracking generation numbers of signed programs. Instead of revoking signatures individually as problems are found, counters are used to indicate that old versions of programs are no longer considered secure. Revoking an old series of GRUB2 binaries (for example) now becomes a case of updating a UEFI variable containing the generation number for GRUB2; any versions of GRUB2 software older than that number will no longer be considered secure. For much more information on SBAT, see the shim SBAT documentation.

Unfortunately, this new shim SBAT development effort is not quite ready yet. Developers were aiming to release a new version of shim now with this major new feature, but hit unexpected problems. Development is still ongoing. Across the Linux community, we are expecting to update to this new version of shim very soon. Until that is ready, we will all be continuing to use our existing signed shim binaries.

Updated versions of Debian's shim packages will be made available as soon as this work is finished. They will be announced here and elsewhere. We will publish a new 10.10 point release at that point, and also release new shim packages for development versions of Debian (unstable and testing).

4. Fwupdate

Updated versions of Debian's fwupdate packages will be available shortly in buster-proposed-updates for the stable Debian 10 (buster) release and will be included with the upcoming 10.10 point release. fwupdate had already been removed from unstable and testing some time ago in favour of fwupd.

5. Fwupd

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

6. Keys

Debian has generated new signing keys and certificates for its Secure Boot packages. We used to use one certificate for all of our packages:

We have now moved to using separate keys and certificates for each of the five different source packages involved, to give us better flexibility in future:

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

All of the fixes described here will be targeted for inclusion in the Debian 10.10 (buster) point release, due shortly. 10.10 would therefore be a good choice for users looking for Debian installation and live media. Earlier images may stop working 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: