(Image credit: Future)

Firmware security company Eclypsium has claimed that 200,000 Framework laptops and desktops that are running Linux have shipped with “what can only be described as signed backdoors.” This is because they’ve shipped with UEFIs that allow memory read/write access that can apparently be used to compromise Secure Boot. And apparently “this situation is not unique to Framework.”

That’s according to the security company, which notes that UEFI shells that enable these vulnerabilities aren’t backdoors placed by bad actors for malicious purposes (via Bleeping Computer). “Instead, they’re legitimate diagnostic tools signed with trusted certificates that contain functionality to effectively bypass security controls we’ve built into the boot process” the company says. “The implications? Systems that have a secure boot process, in reality, do not.”

A UEFI shell is a command-line environment that loads before the operating system boots up. It allows you to perform diagnostics, update your firmware, and so on. Part of what goes on at this pre-OS stage of booting is your system checks whether UEFI applications are signed by Microsoft. If it’s signed, your firmware will trust it and allow it to run things in the UEFI shell.

The problem, however, occurs with one UEFI shell command. Eclypsium explains: “At the heart of this issue is a seemingly innocent command: mm (memory modify). This command, present in many UEFI shells, provides direct read and write access to system memory. While this capability is essential for legitimate diagnostics, it’s also the perfect tool for bypassing every security control in the system.”

(Image credit: Future)

Essentially, it seems like a malicious actor can use this command to directly write to memory, rather than interfacing with the UEFI code/variables themselves, to bypass security verification. The process is as follows:

1. Identify the target variable (gSecurity2)
2. Locate the Memory Address for that variable
3. Patch the security handler, using the mm command to overwrite it with NULL, or redirect it in such a way that makes it bypass verification.
4. Load and execute any UEFI module code now that the security handler is disabled
5. Establish persistence so the bypass happens automatically on each boot

This can allow the malicious actor to completely bypass Secure Boot. This is the part of the booting process I mentioned earlier, where your system verifies that nothing is compromised by checking digital signatures. The “mm” command seems to be able to bypass these checks entirely, which would mean you could then load and execute even non-verified, ie, potentially malicious, code.

This vulnerability has been discovered and tested in Framework Linux systems, and Eclypsium says “this information was disclosed to Framework, and they have been working on remediating the vulnerabilities affecting roughly 200k Framework laptops and desktops.”

Keep up to date with the most important stories and the best deals, as picked by the PC Gamer team.

Given this isn’t just a Framework problem, but presumably a problem with any UEFI shell that allows execution of the “mm” command, the security company thinks it might call for a complete change in approach to security:

“The concept of implicit trust based solely on digital signatures is fundamentally flawed when those signatures can be applied to components with dangerous functionality… those [organisations] that continue to operate under the assumption that ‘signed equals safe’ may find themselves on the wrong side of a fundamental shift in the threat landscape.”

(Image credit: Framework)

Of course, there’s also the fact that older systems don’t run Secure Boot at all, and users can bypass Windows 11 Secure Boot requirements by modifying the install in Rufus, for instance. Although this will become increasingly difficult to get away with for gaming, given more and more games are requiring it and Steam now even lets you check if you have it enabled.

Given that we seem to be decidedly wading into the Secure Boot requirement era, it would be great if we could get it, y’know, actually doing its job and verifying system integrity. Without possible UEFI shell exploits like this, I mean. Perhaps stopping to assume that “signed equals safe” is the way after all. Until then, keep an eye out for BIOS updates from Framework and any other companies that recognise the vulnerability and patch it.

Jacob got his hands on a gaming PC for the first time when he was about 12 years old. He swiftly realised the local PC repair store had ripped him off with his build and vowed never to let another soul build his rig again. With this vow, Jacob the hardware junkie was born. Since then, Jacob’s led a double-life as part-hardware geek, part-philosophy nerd, first working as a Hardware Writer for PCGamesN in 2020, then working towards a PhD in Philosophy for a few years while freelancing on the side for sites such as TechRadar, Pocket-lint, and yours truly, PC Gamer. Eventually, he gave up the ruthless mercenary life to join the world’s #1 PC Gaming site full-time. It’s definitely not an ego thing, he assures us.