Ubuntu Wiki

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

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

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.

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

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
   $ mount /boot/efi

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
GRUB2_VERSION=2.02-2ubuntu8.15
GRUB2_LP_URL=https://launchpad.net/ubuntu/+source/grub2/2.02-2ubuntu8.15/+build/18831561/+files
GRUB2_SIGNED_VERSION=1.93.16
GRUB2_SIGNED_LP_URL=https://launchpad.net/ubuntu/+source/grub2-signed/1.93.16/+build/18831639/+files

$ 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).