Secure Boot Easily Bypassable Using Decade-Old Vulnerabilities

Researchers at ESET discovered that secure boot on Linux and Windows could be bypassed using decade-old UEFI shim bootloaders still signed by Microsoft.

ESET researchers identified 11 old and forgotten UEFI shim bootloaders at versions 0.9 and below that can be used to bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Corporation UEFI CA 2011 third-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS). Reported shims can be exploited to execute untrusted code during system boot, enabling attackers to deploy malicious UEFI bootkits (such as Bootkitty, HybridPetya, or BlackLotus) even on systems with UEFI Secure Boot enabled.

Microsoft revoked the vulnerable UEFI applications in their June 9th Patch Tuesday. The researchers say all systems with third-party UEFI signing enabled are affected, so make sure to update.

Because the issue resides in UEFI firmware, you'll need to update your firmware. The researchers say Windows should handle this for you automatically and on Linux you can use the Linux Vendor Firmware Service (LVFS).

UEFI secure boot works by verifying a UEFI driver or app against two databases of certificates: one of allowed certificates and image hashes and one for revoked ones. For it to execute, the image must be trusted by the allowed database and not present in the revoked database.

Most OEMs use a set of default Microsoft certificates so that everything works out-of-the-box. Developers can submit their binaries to Microsoft so that they work with secure boot by default on most devices.

Every Linux distribution generates its own bootloader binaries, and submitting them all to Microsoft would be nearly impossible. A shim provides the solution to this problem by being a minimal bootloader that Microsoft can sign once, and that then hands the boot process off to the Linux distribution.

The shims authorize secondary boot loaders such as GRUB 2 that then boot the rest of the system. The secondary utilities can be quite outdated and contain their own vulnerabilities though, some of which are quite easy to exploit:

The exploit is simple: there are no memory corruption bugs to trigger, no ROP chains to construct, and no complex reverse engineering required. The single prerequisite is building a custom, unsigned multiboot2-compliant kernel image – in practice, little more than an ELF binary containing the required headers and a handful of other specifics.

The outdated shims themselves can have vulnerabilities as well, the Microsoft certificate dates all the way back to 2011 so anything signed by it could be as old as that, and unless it's been explicitly revoked, it'll boot just fine. Old unpatched code tends to have lots of known vulnerabilities to exploit that don't require an attacker to discover new ones.

The older 2011 certificates have now expired, however the expiration date actually has no effect on secure boot at all. If the certificate is still in the approved database and hasn't been revoked, then it will still boot as if nothing is wrong.

Always make sure to install the latest updates, even in your firmware.