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."
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:
- Identify the target variable (gSecurity2)
- Locate the Memory Address for that variable
- 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.
- Load and execute any UEFI module code now that the security handler is disabled
- 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."
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."
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.
1. Best AM5 - AMD Ryzen 9000/7000:
MSI MAG X870 Tomahawk WiFi
2. Best budget AM5 - AMD Ryzen 9000/7000:
Asus TUF Gaming B650-Plus WiFi
3. Best midrange AM5 - AMD Ryzen 9000/7000:
ASRock B850 Steel Legend WiFi
4. Best AM4 - AMD Ryzen 5000/3000:
Asus ROG Strix B550-E Gaming
5. Best LGA1851 - Intel Core Ultra 200S:
Asus ROG Maximus Z890 Hero
6. Best budget LGA1851 - Intel Core Ultra 200S
ASRock B860 Steel Legend Wi-Fi
7. Best LGA1700 - Intel 14/13th Gen:
MSI MAG Z790 Tomahawk WiFi
8. Best budget LGA1700 - Intel 14/13th Gen:
Asrock B760M PG Sonic WiFi
You must confirm your public display name before commenting
Please logout and then login again, you will then be prompted to enter your display name.
