Two exploits are threatening Secure Boot, but Microsoft is only patching one of them

Alfonso Maruccia

Posts: 1,797   +541
Staff
Facepalm: Microsoft and the PC industry developed the Secure Boot protocol to prevent modern UEFI-based computers from being hacked or compromised during the boot process. However, just a few years later, the technology is plagued by a steady stream of serious security vulnerabilities.

Cybercriminals are currently having a field day with Secure Boot. Security experts have uncovered two separate vulnerabilities that are already being exploited in the wild to bypass SB's protections. Even more concerning, Microsoft is reportedly choosing to patch only one of the flaws, leaving the second unaddressed for now, posing an ongoing threat to PC security.

The first known Secure Boot vulnerability is tracked as CVE-2025-3052. According to Microsoft's security bulletin, this bug can be used to bypass the Windows Secure Boot mechanism and compromise the operating system's boot process. While successful exploitation requires local access and authentication, researchers warn that remote exploitation may also be possible in some scenarios.

The root cause of the flaw lies in several shim modules used to boot Linux operating systems with Secure Boot enabled. The vulnerability affects more than 50 device manufacturers that rely on the same tool to flash firmware onto UEFI motherboards. Developed by DT Research, the tool has been in use since 2022 and is authenticated by Microsoft's own Certificate Authority.

No OEM manufacturer in their right mind would block support for Microsoft's Certificate Authority, which means the CVE-2025-3052 flaw effectively compromises the entire UEFI supply chain. Secure Boot was specifically designed to prevent exactly this type of attack, but the standard is now widely regarded as a security failure and an embarrassment for the PC industry.

Microsoft released a patch for CVE-2025-3052 during this month's Patch Tuesday, revoking 14 cryptographic hashes tied to different versions of DT Research's vulnerable tool. While the update aims to restore trust in the Secure Boot chain, the fix may not be the silver bullet it appears to be.

Enter CVE-2025-47827, a newly disclosed vulnerability affecting a Linux kernel module that handles proprietary storage management software developed by German company IGEL. The issue lies in the shim responsible for loading the GRUB bootloader and initializing the compromised Linux kernel, which, crucially, is also signed by Microsoft.

Zack Didcott, the security researcher who uncovered the flaw, has reported it to Microsoft but has yet to receive a response. Experts warn that CVE-2025-47827 could serve as a near-universal method for bypassing Secure Boot's supposed defenses against bootkits, casting further doubt on the protocol's reliability.

Permalink to story:

 
I've always said the most secure option is to never use it.

That’s the dumbest take possible. Having Secure Boot is better than not. Having everyone reliant on MS Keys is dumb. Rolling your own keys and making it a sane and easy process would be the best method for both Windows and *nix systems.

Right now I know you can self sign kernels and get them accepted by Secure Boot but the process was complicated enough just glancing at it that I was deterred from really trying to do so and I personally stick to distros that support Secure Boot.
 
Is it really a surprise given Microsoft partnered with Cognizant that the quality of updates and security solutions are going down?

The company I worked at employed a boatload of cheap Indians via Cognizant to do the work "expensive" colleagues used to do.

The quality and speed of solutions inside the company dropped by a large margin. One example is their servicedesk, you file a ticket and they ask YOU where to redirect the ticket to, even though that's THEIR job.

They would also keep tickets open for weeks and close it without a solution or even contact. Or better, they call someone on a Sunday in the middle of the night.. and then close ticket because the person didn't answer the phone.

It's not a given in this situation with Microsoft, but I've seen it happen before and it really makes me think of it.
 
Security solutions having bugs is not "failure". Nothing is ever perfect, unfortunately. It's MS failing in this case, not Secure Boot. You got a vulnerability, you patch it. It's not rocket science, but they still didn't get the memo.

And then you patch it again. And again. And again. And again. And again. And again. And again. And... Surely it isn't rocket science, but feels just like bullshit at this point :-D
 
And then you patch it again. And again. And again. And again. And again. And again. And again. And... Surely it isn't rocket science, but feels just like bullshit at this point :-D
It’s not bullshit, that’s how software works. Unless your code is formally proven to be correct, which isn’t very common.
 
That’s the dumbest take possible. Having Secure Boot is better than not. Having everyone reliant on MS Keys is dumb. Rolling your own keys and making it a sane and easy process would be the best method for both Windows and *nix systems.

Right now I know you can self sign kernels and get them accepted by Secure Boot but the process was complicated enough just glancing at it that I was deterred from really trying to do so and I personally stick to distros that support Secure Boot.

I disagree.

Restrict your boot devices, disable USB booting, properly restrict permissions, lock your BIOS, and then consider adopting a higher degree of skeptisim towards Microsoft marketing materials.
 
Is it really a surprise given Microsoft partnered with Cognizant that the quality of updates and security solutions are going down?

The company I worked at employed a boatload of cheap Indians via Cognizant to do the work "expensive" colleagues used to do.

The quality and speed of solutions inside the company dropped by a large margin. One example is their servicedesk, you file a ticket and they ask YOU where to redirect the ticket to, even though that's THEIR job.

They would also keep tickets open for weeks and close it without a solution or even contact. Or better, they call someone on a Sunday in the middle of the night.. and then close ticket because the person didn't answer the phone.

It's not a given in this situation with Microsoft, but I've seen it happen before and it really makes me think of it.

Greed my friend.
Greed and crony US corporations.
 
And then you patch it again. And again. And again. And again. And again. And again. And again. And... Surely it isn't rocket science, but feels just like bullshit at this point :-D

You're acting like this is Adobe Flash Player or IE6. It's not. Secure Boot is actually quite effective. Yes, there are implementation issues frequently. Yes people are dumb enough to turn it off and wonder why it's no longer secure. When enabled and blocked from being disabled, it does significantly improve resistance to tampering.

It's kind of ironic here that the main issue is Microsoft offering support to boot insecure linux distros. I thought this was the crowd that normally wanted more security.
 
I disagree.

Restrict your boot devices, disable USB booting, properly restrict permissions, lock your BIOS, and then consider adopting a higher degree of skeptisim towards Microsoft marketing materials.
Or maybe I just listen to people like Matthew Garret and not MS marketing materials because I’m a Linux guy? Or Linus Torvalds?

Besides, there isn’t much I can do to restrict my BIOS besides putting an admin password on the damn thing besides yes disabling PXE and USB boot and disabling legacy/compatibility mode. If there is more, do enlighten me but I don’t recall seeing many options in Dell/HP/Lenovo BIOS.
 
Security solutions having bugs is not "failure". Nothing is ever perfect, unfortunately. It's MS failing in this case, not Secure Boot. You got a vulnerability, you patch it. It's not rocket science, but they still didn't get the memo.

Or perhaps Microsoft accepted a long time ago that Secure Boot did not get implemented in an effective way.. so now they just try to patch a leaky ship in places where it does not break other functionality, while knowing its kind of pointless.
 
Back