Researchers have unearthed two publicly available exploits that completely evade protections offered by Secure Boot, the industry-wide mechanism for ensuring devices load only secure operating system images during the boot-up process. Microsoft is taking action to block one exploit and allowing the other one to remain a viable threat.
As part of Tuesday’s monthly security update routine, Microsoft patched CVE-2025-3052, a Secure Boot bypass vulnerability affecting more than 50 device makers. More than a dozen modules that allow devices from these manufacturers to run on Linux allow an attacker with physical access to turn off Secure Boot and, from there, go on to install malware that runs before the operating system loads. Such “evil maid” attacks are precisely the threat Secure Boot is designed to prevent. The vulnerability can also be exploited remotely to make infections stealthier and more powerful if an attacker has already gained administrative control of a machine.
A single point of failure
The underlying cause of the vulnerability is a critical vulnerability in a tool used to flash firmware images on the motherboards of devices sold by DT Research, a manufacturer of rugged mobile devices. It has been available on VirusTotal since last year and was digitally signed in 2022, an indication it has been available through other channels since at least that earlier date.
Although the module was intended to run on DT Research devices only, most machines running either Windows or Linux will execute it during the boot-up process. That’s because the module is authenticated by “Microsoft Corporation UEFI CA 2011,” a cryptographic certificate that’s signed by Microsoft and comes preinstalled on affected machines. The purpose of the certificate is to authenticate so-called shims for loading Linux. Manufacturers install it on their devices to ensure they’re compatible with Linux. The patch Microsoft released Tuesday adds cryptographic hashes for 14 separate variants of the DT Research tool to a block list stored in the DBX, a database listing signed modules that have been revoked or are otherwise untrusted.
Unfortunately, it was a long process to communicate the extent of the vulnerability, and for it to pick up any traction. I coordinated with the vendor and agreed on public disclosure dates, before sharing any details.
Microsoft also dismissed the report after about a week, as they believed it was not their responsibility, due to the vulnerability existing within the igel-flash-driver, rather than the shim signed by them.
As others have mentioned, this highlights the current state of Secure Boot; while it can be an effective gatekeeper, users should be wary of who/what they are implicitly trusting. If not needed, the Microsoft 3rd Party UEFI CA should be distrusted. For Linux users, I also recommend generating and enrolling your own keys, to sign a unified kernel image. These can be generated automatically after a system upgrade.