Ubuntu Wiki

CVE-2019-20810

GRUB2 UEFI Secure Boot Bypass (aka There’s a Hole in the Boot/BootHole) (CVE-2020-10713)

It was discovered that GRUB2 contained various vulnerabilities that would allow UEFI Secure Boot to be bypassed. A local attacker with administrative privileges (or with physical access to the system) could use this issue to circumvent GRUB2 module signature checking, resulting in the ability to load arbitrary GRUB2 modules that have not been signed by a trusted authority and hence bypass UEFI Secure Boot.

A number of separate CVEs were allocated for these various vulnerabilities:

DBX Update

Remediation of this vulnerability involves not only updated versions of grub2, but also an update to the UEFI Secure Boot DBX entries so that previously released vulnerable versions of grub2 are denied from being loaded. In the case of Ubuntu, this is achieved by adding the 2012 Canonical UEFI on-line signing key to the UEFI DBX as this was used to sign all grub2 binaries with this vulnerability. Fixed grub2 binaries are now signed by a new 2017 Canonical UEFI on-line signing key. The update for the UEFI DBX will be provided by an updated version of the secureboot-db package in Ubuntu at a later date, once this has undergone validation.

For users wishing to apply the DBX update before this is released for Ubuntu, it can be obtained from the UEFI Forum Revocation List File.

Dual-boot and multi-boot users need to take special care to update all their operating systems before installing DBX updates, whether received from Ubuntu, another operating system, or via the UEFI Forum. Updating the DBX list is similar to a BIOS update: Secure Boot is a feature of the motherboard and is shared in common among all operating systems on the computer.

An update from another operating system may include DBX updates that will prevent you from booting unrelated operating systems. We expect other operating systems to release staggered updates that will provide new GRUB bootloaders before they release DBX updates. We do not know when other operating system vendors will release DBX updates. Ubuntu currently plans to release our DBX update in the near future.

Please plan to boot into every operating system on your multi-boot systems and install updates as soon as your other operating system distributions publish updates for this issue.

16.04 LTS FIPS

Currently, the versions of grub2 / grub2-signed in Ubuntu 16.04 LTS do not enforce Secure Boot signature verification because the Linux kernel provided for 16.04 LTS FIPS is not signed. In conjunction with the remediation of this issue, the forthcoming re-certified FIPS kernel for Ubuntu 16.04 LTS will be signed and grub2 / grub2-signed packages *will* enforce Secure Boot validation of the kernel. Until this updated kernel is available for 16.04 LTS FIPS customers, it is advised that for customers who have Secure Boot enabled with 16.04 LTS FIPS, to pin the FIPS repository on their machine to avoid grub2 / grub2-signed updates as follows:

$ cat <<EOF | sudo tee /etc/apt/preferences.d/ubuntu-fips
Package: *
Pin: release o=LP-PPA-ubuntu-advantage-fips, n=xenial
Pin-Priority: 1001
EOF
$ sudo apt-get update

Fixed versions

This issue was fixed in grub2 in 2.06. Ubuntu 14.04 ESM, 16.04 LTS, 18.04 LTS and 20.04 LTS were affected. To address the issue, ensure that the appropriate versions of the grub2 and grub2-signed are installed. These updates were announced in USN 4432-1.

These versions are signed with a new key and fix the discovered errors that would allow secureboot bypass:

Some users on cloud providers, legacy BIOS computers, or UEFI configured to boot with legacy support, have reported problems booting with the above versions. If you installed the above versions but have not yet rebooted, please double-check that debconf knows where your grub should be installed:

sudo apt install debconf-utils
sudo debconf-get-selections | grep -E 'grub-(efi|pc)/install_devices[^_]'

Use dpkg-reconfigure to repair the configuration:

sudo dpkg-reconfigure grub-pc

(Alternatively, you can simply run sudo dpkg-reconfigure grub-pc without checking first. It is harmless to run this multiple times.)

The following versions no longer reinstall grub when grub-pc is upgraded, to reduce the chance of regression due to bug 1889556. These updates were announced in USN 4432-2.

Timeline

• 2020 Apr 07: Initial notification of issue received by Eclypsium researchers
• 2020 Apr 07: Co-ordination with Eclypsium researchers to report the issue upstream
• 2020 Apr 22: Begin co-ordination with grub2 upstream and other Linux distributions
• 2020 Jul 29: CRD

• 2020 Jul 29: Ubuntu published updated grub2 and grub2-signed packages

• 2020 Jul 31: Ubuntu published updated grub and grub2-signed packages for Ubuntu 20.04 LTS, 18.04 LTS, and 16.04 LTS to address a regression on incorrectly-configured legacy boot systems, and reverted the packages for Ubuntu 14.04 ESM. Updated packages for Ubuntu 14.04 ESM will be published on Mon, Aug 3rd, 2020.

References

• https://www.eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/

• https://ubuntu.com/security/notices/USN-4432-1

• https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011

• https://access.redhat.com/security/vulnerabilities/grub2bootloader

Recovery

In the unlikely case that updating grub2/grub2-signed results in boot failure, the system can be recovered by downgrading grub2/grub2-signed from a separate running Ubuntu session. In the case of a physical machine, this can be done via the bootable Ubuntu Live CD / USB installer. In the case of a machine in the cloud, a separate instance on the same cloud availability-zone is required. In both cases, the final steps are the same - mount the root volume / device from the affected system into the livecd / separate cloud instance, chroot into this and use apt to downgrade grub2/grub2-signed:

Prepare the chroot

Preparing the chroot will be different depending on if this is a physical install or cloud instance.

Physical machine

1. Create a bootable Ubuntu CD/DVD/USB image and then when booting this, select ‘Try Ubuntu without installing’. You can find current installation media at http://releases.ubuntu.com/ and old installation media at http://old-releases.ubuntu.com/releases/.

2. Within the livecd environment, mount the root partition from the affected disk as well as various ephemeral file-systems, and chroot into it:

   $ sudo mount $ROOT_PARTITION /mnt # see with ‘gdisk -l /dev/<device>
   $ for i in /sys /proc /run /dev /dev/pts ; do sudo mount --bind "$i" "/mnt$i"; done
   $ sudo mv /mnt/etc/resolv.conf /mnt/etc/resolv.conf.bak # will restore later
   $ sudo cp -L /etc/resolv.conf /mnt/etc/
   $ sudo chroot /mnt
   $ mount /boot/efi

Cloud instances (e.g. AWS EC2)

These instructions use AWS EC2 as an example but the process is similar in other clouds where the root disk can be detached from the VM. Google Compute Environment instructions can be found at https://cloud.google.com/compute/docs/disks/detach-reattach-boot-disk. Azure requires deleting the VM to attach the root disk to a separate instance for recovery, those instructions can be found at https://docs.microsoft.com/en-us/archive/blogs/mckittrick/how-to-delete-a-vm-and-attach-the-os-disk-as-a-data-disk-to-a-recovery-vm-arm.

1. Create a second cloud instance (if one does not already exist) in the same availability zone as the affected machine

2. Determine the root EBS volume of the affected instance, stop that instance and detach the root volume, then attach it to the second cloud instance from above

   instance_a=i-XXXXXXXX # the affected instance
   instance_b=i-YYYYYYYY # the second instance
   root_device=$(aws ec2 describe-instances \
     --instance-ids $instance_a \
     --output text \
     --query 'Reservations[*].Instances[*].RootDeviceName')
   volume=$(aws ec2 describe-instances \
     --instance-ids $instance_a \
     --output text \
     --query 'Reservations[*].Instances[*].BlockDeviceMappings[?DeviceName==`'$root_device'`].[Ebs.VolumeId]')
   aws ec2 stop-instances --instance-ids $instance_a
   aws ec2 detach-volume --volume-id $volume --output text --query 'State'
   aws ec2 attach-volume  --volume-id $volume --instance-id $instance_b --device /dev/sdj

3. ssh into the second instance

4. Mount the affected volume and chroot into it

   $ sudo mount /dev/xvdj1 /mnt
   $ sudo mount /dev/xvdj15 /mnt/boot/efi
   $ for i in /sys /proc /run /dev /dev/pts; do sudo mount --bind "$i" "/mnt$i"; done
   $ sudo mv /mnt/etc/resolv.conf /mnt/etc/resolv.conf.bak # will restore later
   $ sudo cp -L /etc/resolv.conf /mnt/etc/
   $ sudo cp /cdrom/ubuntu/pool/main/g/grub2*/*deb /mnt/tmp
   $ sudo chroot /mnt

Downgrade `grub2`/`grub2-signed` to the previous version for recovery

The previous version of grub2/grub2-signed will be different depending on the given Ubuntu release - these are summarised in the following table for amd64 (for other architectures, navigate to them via https://launchpad.net/ubuntu/+source/grub2 and https://launchpad.net/ubuntu/+source/grub2-signed for your release):

Once the required versions are identified from the table above, grub2/grub2-signed can be downgraded as follows from within the chroot environment. Since the previous versions are no longer available via apt, we must download the previous versions of debs and install them with dpkg. This example uses the versions for Ubuntu 18.04 LTS with typical installation packages, so these should be replaced with the appropriate versions for the given install and for packages (see 'dpkg -l | grep grub' to see what to fetch via wget). Eg:

# inside chroot from above (can use the links from the above table for GRUB2_LP_URL and GRUB2_SIGNED_LP_URL)
GRUB2_VERSION=2.02-2ubuntu8.15
GRUB2_LP_URL=https://launchpad.net/ubuntu/+source/grub2/$GRUB2_VERSION/+build/18831561/+files
GRUB2_SIGNED_VERSION=1.93.16
GRUB2_SIGNED_LP_URL=https://launchpad.net/ubuntu/+source/grub2-signed/$GRUB2_SIGNED_VERSION/+build/18831639/+files
$ cd /tmp
# on focal, omit grub-efi and grub-efi-amd64
$ for i in grub-common grub-efi grub-efi-amd64 grub-efi-amd64-bin grub2-common ; do wget $GRUB2_LP_URL/${i}_${GRUB2_VERSION}_amd64.deb ; done
$ wget $GRUB2_SIGNED_LP_URL/grub-efi-amd64-signed_${GRUB2_SIGNED_VERSION}+${GRUB2_VERSION}_amd64.deb
$ dpkg -i ./grub*.deb
$ cp -df /etc/resolv.conf.bak /etc/resolv.conf

Then finally exit the chroot and unmount the root device / volume (and detach + re-attach it to the original instance for a cloud instance).

Known issues

Existing Cloud / MAAS instances may fail reboot

For Cloud and MAAS images there was a cloud-init issue, bug #1877491, where the grub install devices were not correctly set at first boot. Existing instances that received the fix for that bug did not have the configuration fixed. There is an underlying grub issue, bug #1889556, where an incorrect install device causes grub-install to fail during package upgrade but the installation still proceeds, whereas it should fail the grub install. This leaves the system with grub modules on the filesystem that are newer than grub core on the boot device which causes the instance to fail to reboot, bug #1889509, from the mismatch.

Workaround

Before rebooting run sudo dpkg-reconfigure grub-pc. A wizard will walk you through the grub configuration options. You can select the default options until you get a list of install devices. If your instance is affected by this issue you will first see a message that the install device is no longer present:

Proceed to the next screen and select all devices when prompted for a grub installation device.

At the end of the reconfiguration grub-install will update the bootloader.

Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.4.0-1109-aws
Found initrd image: /boot/initrd.img-4.4.0-1109-aws
done