The recently revealed BootHole security problem with GRUB2 and Secure Boot can, theoretically, be used to attack Linux systems. In practice, the only vulnerable Linux systems are those that have already been successfully breached by an attacker. So, despite all the publicity BootHole got, it really wasn’t that big a problem. Still, almost all enterprise Linux distributors released patches. Unfortunately, for several of them, including Red Hat, the fix proved worse than the security hole. Users found their newly “repaired” systems wouldn’t boot. Now, the fixes to these fixes are out.
Red Hat jumped on the problem immediately. Peter Allor, director of Red Hat’s Product Security Incident Response Team, told me:
Red Hat has been made aware of a potential issue with the fix for CVE-2020-10713, also known as BootHole, whereby some Red Hat Enterprise Linux 7 and Red Hat Enterprise Linux 8 systems may not successfully reboot after the remediation is applied, requiring manual intervention to fix. We are currently investigating this issue and will provide more information as it becomes available.
Unfortunately, the fix took several days instead of hours to pull together. Now, though, the fix is ready for deployment on Red Hat Enterprise Linux (RHEL) 7.8 and 8.2. While the solution hasn’t been confirmed yet for RHEL 7.9 and 8.1 Extended Update Support (EUS), it should work on them as well.
The repair consists of updated shim packages. A shim in this context is a UEFI (Unified Extensible Firmware Interface) Secure Boot certificate. It’s signed by the Linux distributor, which is implicitly trusted by being embedded in the Microsoft signed shim loader. Microsoft’s UEFI Secure Boot is used because almost all computers come preloaded with Microsoft Secure Boot keys.
These updated shim packages are available now. You can use them with the previously released grub2, fwupd, and fwupdate packages. To perform the fix, you’ll need to reboot using the RHEL DVD in Troubleshooting mode. Once booted, you enter the chroot container, and replace the faulty shim package with the repaired version.
With the RHEL clone operating system CentOS, you fix it with a similar method. Be sure to read the CentOS BootHole repair bug report all the way to the end. Instead of reverting to an old booting shim, as described in the report’s beginning, you’ll be upgrading to shim-x64-15-15.el8_2.x86_64.rpm (EL8) or respectively shim-x64-15-8.el7_8.x86_64.rpm (EL7) (or newer) as described in the report’s final note.
Red Hat staffers told me that the unbootable system issue never hit Fedora, Red Hat’s community Linux distribution. Fedora programmers are currently working on delivering the broad fix for BootHole in the near future. “That said, given the very narrow attack surface of BootHole (already requiring access, etc.) it’s viewed as a serious but not overly critical issue.”
Canonical, Ubuntu Linux’s parent company, reports that it’s seen very few instances of systems not booting with their BootHole patch. In the event, you do run into one, Canonical suggests, downgrading grub2/grub2-signed from another Ubuntu session. With a local machine, you do with a bootable Ubuntu Live DVD or USB stick. On the cloud, you do it from a separate instance on the same cloud availability-zone. Either way, you use the same final steps. That is, mount the root volume/device from the affected system into the live/separate cloud instance, chroot into it, and use apt to downgrade grub2/grub2-signed/.
As for Debian Linux, the corrected BootHole fix comes in the latest Debian 10 “Buster” release: Debian 10.5.
If your Linux distro of choice doesn’t have a fix yet, I have a suggestion. Wait. Don’t patch your system until you know that the real repair has been made. Usually, I’m all about patching security bugs as soon as possible. This is an exception. BootHole is not really a serious problem, but not being able to run your system because of a botched patch is as bad as it gets. Wait. The real fixes are out there and will be coming to your distribution in good time.
Related Stories:
