Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass
113 comments
·June 10, 2025jrm4
lmm
Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.
miki123211
I suspect the actual reason is a lot more banal, it's enterprises asking for it.
People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again. Those are the people driving the concerns of Microsoft and computer vendors.
PeterStuer
If by 'enterprises' you mean Disney and Sony, I fully agree.
lmm
> People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again.
How does secure boot help with that? Those kind of users aren't going to be pulling the CMOS battery to reset the BIOS password.
HPsquared
With laptops, unauthorized physical access happens a lot more often. People lose them, they get stolen, etc.
Y_Y
Presumably drive encryption is necessary anyway to protect lost/stolen devices, and at that point modifying the bootloader won't be useful.
I see the value when the attacker manages to modify the device without the user knowing, and causes them to unknowingly use an attacker-controlled OS, but that's a vastly different threat model.
heavyset_go
Stick a BIOS password on your machine and turn on Secure Boot.
Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc.
You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered.
Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run.
This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.
fsflover
> you are now secure against petty criminals stealing your data
Ordinary disk encryption would protect me too here, wouldn't it?
npteljes
I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk.
https://security.stackexchange.com/questions/267222/full-dis...
So, there are two scenarios here.
First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe.
Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.
heavyset_go
Unless your BIOS/UEFI supports full disk encryption unlocking of hardware-encrypted Opal drives, you will always have an unencrypted bootstrap process at early boot from the disk.
That unencrypted bootstrap process can be modified by anyone with access to the disk, physical or remote. Theoretically, someone can inject a keylogger into the process and exfiltrate your encryption key's password, or a process that waits until you're decrypted and exfiltrates your data. It's also a potential vector for ransomware, root/boot kits, etc.
mjg59
You should be able to do what you want to it. You should also be able to configure it such that only you can do what you want to it, and nobody else can.
Secure Boot protects against boot kits, malware that replaces the bootloader and backdoors the OS as it boots and before any other security protections kick in. Real world bootkits have been found in the wild, and we've even seen them use vulnerabilities in signed (now revoked) bootloaders, so we know secure boot has forced their developers to work harder. You may not be worried about that as a risk (well, until you are) but there are real people who this has genuinely protected.
Is it worth it by default? Completely reasonable separate discussion to have. But is there a reason it exists? Absolutely.
JCattheATM
> I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS.
Apart from way nicer boot menus and bootloader setup?
In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression.
> Out there, there is software, which I have to figure out how I'm going to trust,
Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
necovek
It's mostly about your UEFI firmware coming with a set of trusted CAs to verify bootloader is built by one of the trusted parties like Microsoft or Canonical or Redhat or...
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
josefx
Unless the software vendor requires it to be locked down hard. Microsofts certification requirements for ARM devices back in 2012 explicitly required secure boot and prohibited custom certificates.
c0l0
It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on top of these vendors' platforms - refuse to work on your machine.
mjg59
Which vendors?
RiverCrochet
If an attacker gains root privileges on your system, an attacker can modify the bootloader on your boot device to load a different kernel than the one you have installed, possibly one that the attacker uploaded that may have backdoors, etc.
Secure boot requires that the bootloader match a hash derived from a TPM-stored key.
Of course, you get the same protection (and update hassle) by storing the bootloader in something that can't be written except when you specifically enable it.
A better scheme than the UEFI secure boot/TPM junk is simply a 2GB SD card (enough to hold a bootloader, kernel, and initrd) in an SD card reader with a physical read/write switch. When it's time to update your bootloader or kernel, flip the switch to write mode, then flip it back - heck the system could even refuse to boot if write mode was enabled on boot.
Honestly I don't know why the whole PC firmware shouldn't be on that SD card. Corrupt unbootable BIOSes can be fixed with a new SD card.
For remote updates, the physical switch could be replaced with a GPIO pin and a Raspberry Pi that you connect to and log into separately. It's less secure than the physical switch but oodles more secure than what's there now - maybe not oodles but at least the software on a Pi is much higher quality than UEFI vendors.
mjg59
> Secure boot requires that the bootloader match a hash derived from a TPM-stored key.
This isn't even slightly accurate. Secure boot does not rely on TPM keys on any way.
RiverCrochet
Huh, I don't know why I thought it did. Looking into the link below briefly I see it uses a PKI scheme with CAs.
https://learn.microsoft.com/en-us/windows-hardware/manufactu...
So I guess if you provide a key for the bootloader, the firmware will sign it when it's in setup mode? I guess that private key is embedded directly in the firmware then? I presume that's made invisible once control is handed to the bootloader somehow ...
jrm4
"If an attacker gains root privilieges.."
LOLOL lemme stop ya right there chief. I'm screwed anyway? This is ridiculous.
Nextgrid
"BIOS vs UEFI" and Secure Boot are two different things.
UEFI supports the latter if you want and configure it, but it's not a requirement of UEFI, and technically a BIOS could also implement signature verification of the boot sector.
FirmwareBurner
>I own a piece of hardware, so I can do what I want to it.
It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other potential bad actors.
autoexec
Then why force it into consumer hardware? If it were only available on enterprise servers nobody would care.
FirmwareBurner
>Then why force it into consumer hardware?
It's not forced. You can disable secure boot and all that in BIOS.
pabs3
I wish the hardware industry went more in the direction of the State Considered Harmful paper:
https://blog.invisiblethings.org/papers/2015/state_harmful.p... https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably...
db48x
> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables.
Sheer incompetence, in other words.
OjotCewIo
UEFI variables or not: who in their right mind serializes raw pointer values to any kind of storage (network, disk, nvram, ...)?
Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types? I'd like to understand the economics and the psychology behind it.
db48x
It’s something about hardware companies writing software. The motherboard itself may be excellent, but the BIOS/UEFI/ACPI tables will be horrible.
Meanwhile you look at a company like Oxide that is a software company at heart, and their equivalents are so much better. Like someone actually designed it so that when humans write the software it will still be secure.
neilv
> It’s something about hardware companies writing software.
I've seen enough examples of that, to suspect there's some truth to it, and wonder why that is...
Speculation:
* Systems programming is hard, and systems programmers who are familiar enough with the kind of target hardware are even more rare. A company might decide to hire a hardware engineer who can code, rather than a systems programmer software engineer who knows enough hardware.
* Hardware companies know hardware, and might have hardware engineers as execs and managers, so they probably know how to hire hardware engineers, but maybe not software engineers.
* Hardware companies respect hardware engineers, and not so much software people. You don't need all those hard math and engineering classes to be a "coder". Even their 12yo can make an app, but you usually need a team with a ton of hardware education and experience to produce a viable board or IC. ("Coding" even sounds like a tedious but straightforward clerical task.)
Other speculation, or does anyone know?
bradfa
I have a ton of respect for what Oxide did by not using an off the shelf firmware for their Epyc chips. But unless you’re them, AMD is going to send any small customer to Insyde to buy their UEFI and AMD is not going to give you the kind of access and info that normal engineering teams would expect to get in order to implement their own firmware for Zen based Epyc chips.
Most small customers have no choice but to buy a preexisting firmware from an IBV and you get all their security bugs included. You’re lucky if you get full source code and it actually compiles. This is the state of our industry today.
scraptor
When's the last time you made a motherboard purchase decision on the basis of firmware quality? Or rather, when's the last time a corporate purchasing manager got fired for buying motherboards with low quality firmware?
db48x
At the Internet Archive we occasionally had to return big batches of hard drives because of firmware bugs. That had to have ruined someone’s day, but apparently not enough to actually level up their engineering so that it wouldn’t happen again.
coderatlarge
> When's the last time you made a motherboard purchase decision on the basis of firmware quality?
i would argue every apple macbook purchase implicitly includes this.
gmueckl
Security is competing with all other requirements that a product has. That's all there is to it.
eviks
The economics is there is little cost to having vulns, so you don't incur the extra cost to hire/push devs to code securely?
EPWN3D
They're not. They're ravaged by probably the same quality or slightly higher than average. The cost of mistakes is just way higher.
quotemstr
> Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types?
Lemon market: https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf
Buyers can't distinguish good work from bad, so they pay only average price and thereby drive out the high-quality sellers.
getcrunk
Yea but when things like this keep happening … it becomes a pattern. A very convenient one at that.
candiddevmike
This is all too common with any kind of user infantilizing security feature. Trust us bro, it's secure.
ahepp
I'm not sure I understand why secure boot is user-infantilizing? I think there are some legitimate concerns about where attestation could be headed, but I like the ability to force my machine to only run signed executables.
It seems like the immediate problem here is that most people will never enroll their own keys, and if every vendor's crappy EFI binary gets signed by Microsoft, there will be a huge library of garbage vendor code which is all an attack surface.
AnthonyMouse
The problem here is that the signature doesn't do anything for you.
Suppose you want to be assured of the software running on your machine. You go into the firmware, point it at your boot loader and say "only this one". It makes a hash of the boot loader and refuses to use any other one until you change the setting, which requires your firmware password. Your boot loader then only loads the operating systems you've configured, and so on.
That doesn't require any certificates and you get 100% of the benefits. The firmware needs to verify the boot loader and the boot loader the OS etc. The OS doesn't need to verify the firmware because it can't because if the firmware or boot loader was compromised then the code in the OS to validate it would be just as compromised.
The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.
And then you also don't get this "garbage code is nonetheless trusted" problem because there is no global root of trust and you never told your firmware to trust this random firmware update utility for somebody else's hardware.
baxtr
> Because the attacker’s code executes before the operating system even loads, it opens the door for attackers to install bootkits and undermine OS-level security defenses.
Excellent.
fsflover
Fortunately there's a FLOSS alternative: TPM with Heads, https://osresearch.net/. Works for me.
getcrunk
What hardware do you use the most recent supported seems like the Librem offerings. Which are intel 10th gen. Otherwise it’s gets pretty ancient
fsflover
Indeed I'm using a Librem laptop with Pureboot. Librem 14v1 has been discontinued, Purism is developing the second version, hopefully with a newer CPU.
1oooqooq
why not secure boot with your own keys?
... granted, effectively removing Microsoft keys is a pain on some consumer devices, but still easier than this
dietr1ch
My first encounter with UEFI turned out to be quite expensive because UEFI was way too new and easy to brick. I guess things are better now, but toying around with this might still be a risk not worth taking as a consumer.
hulitu
> I guess things are better now,
A bit. But compared to BIOS is still crap. The main advantage of UEFI over BIOS is that it offers RCE. /s
jerhewet
Please ... just give me back my BIOS.
gruez
BIOS isn't magically secure either. It has no secureboot so it just runs whatever.
lmm
In theory, sure. In practice I'd bet UEFI-based systems are easier to compromise, because the attack surface is just so much larger.
adrian_b
Nevertheless, it is trivial to make any BIOS-based computer at least as secure as the most secure UEFI/secureboot-based computers.
For that, any SSDs/HDDs included in the computer should be non-bootable and fully-encrypted.
Then the BIOS will happily run whatever an intruder will attempt to run, but nonetheless the intruder will not have any access, neither for reading nor for writing, to the data hosted by the computer.
The owner can boot from a removable USB memory, used as a computer key, whose content cannot be modified by someone else as long as the owner keeps it.
All Intel/AMD CPUs have backdoors in the form of the System Management Mode and of various hardware management engines, which can be exploited by a malicious BIOS or UEFI firmware to monitor what the operating system that is controlled by the user does, but SecureBoot also offers no protection against such backdoors. ARM CPUs are no better, because many of them have copied Intel, so they have the equivalent of the SMM: EL3.
If you run yourself a hostile application after booting, then SecureBoot also does not offer any protection against that.
JCattheATM
> Nevertheless, it is trivial to make any BIOS-based computer at least as secure as the most secure UEFI/secureboot-based computers.
Mmm....no.
I use my own keys and removed vendors keys from my secureboot setup. Hard disk is encrypted and automatically pulls keys from the TPM to boot into a guest OS, which is running something akin to prey. If the hard drive is removed, it can't be read or examined, and you can't replace the HDD with a different OS to get it to boot.
How would you recreate that setup with just a BIOS?
Lammy
I refuse to endorse any mindset where my Personal Computer unquestionably running my code could be considered a bad thing.
gruez
You're conflating UEFI with secureboot. Moreover all the secureboot implementations I've seen allow you to either disable it or enroll your own keys.
hulitu
secureboot also runs "whatever". It is just picky about which "whatever" it runs (hint: it runs the "whatever" for which Microsoft has the keys).
null
jeffrallen
A fish, a gun, and a smoking barrel. Sigh.
vitarnixofntrnt
[dead]
I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS.
I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.