Six fournisseurs livrent des chargeurs de démarrage Shim vulnérables - Microsoft révoque enfin les clés de démarrage sécurisées

Six vendor-specific builds of the UEFI shim bootloader, based on versions 0.7 through 0.9, remained signed and trusted by Secure Boot for years despite known upstream vulnerabilities. ESET's Martin Smolar identified the gap: vendors forked the open-source shim project, applied none of the upstream security fixes, and Microsoft's signing certificate kept them alive. Now Microsoft is finally revoking those bootloaders by adding them to the UEFI Forbidden Signature Database (DBX).

The Shim Gap: Why Old Bootloaders Stayed Trusted

The shim project is a tiny signed bootloader that bridges UEFI firmware to Linux distributions under Secure Boot. It lets distros use their own Machine Owner Keys (MOKs) without embedding every key in motherboard NVRAM. But shim 0.7, 0.8, and 0.9 carried multiple security bugs that were later fixed upstream. Vendors like RedHat (RHEL 7.2, CentOS 7.2), baramundi (Management Suite up to 2024R1), WhiteCanyon/Blancco (WipeDrive 8.0–8.1.3), PC-Doctor (Service Center 15–16), Oracle Linux 7.2, OpenSuse (Shim 10.1 and 2.1), and Finland's Abitti exam environment froze their custom builds. Those frozen builds never received the patches. Because Microsoft had signed the originals, Secure Boot continued to treat them as trustworthy.

What a BYOVD Attack Looks Like in the Boot Chain

An attacker with admin rights or physical access can drop one of these old shim binaries onto the EFI system partition. At boot, the UEFI firmware loads the signed shim before Windows or Linux even starts. The vulnerable shim then loads a malicious bootloader or kernel that would otherwise be blocked by Secure Boot. That code runs with full hardware privileges, can install persistent rootkits, and evades OS-level defenses like EDR because it executes before the OS initializes. ESET's research calls it a Bring Your Own Vulnerable Driver (BYOVD) style exploit, but shifted to the boot phase. Once compromised, the machine stays compromised across reboots and even OS reinstallations, unless the firmware itself is cleaned.

Fixing the Gap: DBX Revocation and Audit Tools

Microsoft will push the DBX update containing the SHA256 hashes of every vulnerable binary. After the update, Secure Boot will refuse to load those shim versions. But the fix requires careful deployment order: update the authorized signature database (DB) first with new trusted boot components, then apply the DBX revocation list. Reverse the order and systems may reject newly signed bootloaders. Enterprises should test on non-critical hardware first. Microsoft provides the DBX files and tooling in the secureboot_objects GitHub repo. Audit scripts like Check-UEFISecureBootVariables (PowerShell) and uefi-dbx-audit (Linux) confirm whether the revocation landed. Cloud operators running UEFI-based VMs should prioritize this update — the attack surface applies equally to virtual firmware.

This coordinated disclosure closes a multi-year supply chain blind spot. The lesson for vendors: forking an open-source bootloader means owning its security for the entire product life. Microsoft's DBX revocation is the enforcement mechanism, but the next fork is already waiting in some engineering team's repo.

Source: VU#616257: Microsoft-signed UEFI shim bootloaders vulnerable to Secure Boot bypass
Domain: kb.cert.org