Exploiting signed bootloaders to circumvent UEFI Secure Boot (2019)
habr.com
habr.com
From that mindset what makes sense are hardware vendors including a cache of trusted third party root certificates from known other vendors. Today this would include Microsoft, the same said hardware vendor, probably various respected Linux organizations/groups (Offhand, Linux Foundation, ArchLinux, Debian, IBM/RedHat, Oracle, SUSE, etc), similar for BSD...
Crucially the end user should then be ASKED which to enable. None should be enrolled out of the box. They might also be enabled only for specific things. E.G. HW vendor could be enabled only for new system firmware signatures (load using the existing software) rather than generic UEFI boot targets. The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. This would be a great place to stash things like UEFI drivers for accessing additional types of hardware drivers, OS boot bits + small related files, etc. I would have said 1GB of storage would be more than sufficient for this - however Microsoft has proven that assumption incorrect. Still it'd be nice to have a standard place and a feature that says the system ships with this much reliable secondary storage included (or maybe 1-2 micro-SD card slots, etc).
except, on the other side of the "strange fellows" are people who rose to executive authority by ruthless focus on control of every aspect of their business, and profit including excluding others who did actual work. There is zero point zero chance of any argument that relies on "should" to work IMHO
this is a political situation by definition -- vastly different yet connected members of society and economics, seeking the rule of law to enable stable markets. hint- some of the same decision makers are the ones that pay to put spy code in your large new TV or appliances.
IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
This way it is entirely agnostic of any cherrypicked list of "trust me" vendors. You'd still have most of the benefits of easy secure boot enrolling for those that don't know what it even is/how to do it while also allowing easy choosing of other OSes (at least on initial first boot).
The main problem currently is option-ROM which has a tendency to cause the system to not even POST if secure boot is enabled without MS keys. Recently bricked a MoBo this way and even though it has 2 BIOS I can't actively choose which one to boot, it just has some "trust me, I know when" logic that chooses... well guess how well that is working for me...). The Asrock board I replaced it with though has an option for what it should do with such option-ROM when secure boot is active (don't run, always run, run if signed, ...)
> The user should also be able to enroll their own CA certs as well; multiple of them. Useful for Organization, Division Unit, and system local signatures.
Isn't this already the status quo??
> It would also, really, be nice if UEFI mandated a uniform access API (maybe it does) for local blobs stored in non mass-storage space. [...]
I think UEFI is already complex enough and most of this can in a way already somewhat be handled by the EFI System Partition, e.g. systemd-boot can tell the UEFI to load (file system) drivers off of it (https://wiki.archlinux.org/title/Systemd-boot#Supported_file...), I don't know if UEFI technically supports other types of drivers to be loaded.
Nobody wants to "install" an operating system. Computers should come with an OS preinstalled and ready to run. Everything else is a dead letter in terms of the marketplace.
Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them.
This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens.
See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/syst...
If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
Baseless FUD. If you have an actual point to make then do so.
> All of these "add more nag screens for freedom"
No one said anything about a nag screen. You literally just made that up.
For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader.
This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot?
PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you.
To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine.
> No one said anything about a nag screen.
The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today.
> For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader
So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.
No single point of failure will protect you fully. UEFI SB is just one layer. And nobody ever would protect you from a dedicated nation state (except another nation state). Unless you own the entire supply chain from silicon contractors all the way up to every single software vendor and every single network operator, you cannot fully prove things aren't snitching on you.
People have broken into bank vaults. That doesn't mean that bank vaults don't provide meaningful security.
> So do UEFI systems. Install OS, test boot, enroll PK.
"Enroll PK" is "draw the rest of the fucking owl" territory.
I believe you somewhat misunderstood OP. The description was of the empty hardware. Typical hardware would ship with an OS already installed and marked as trusted. It's the flow for changing the OS that would be different.
> automatically enroll the first key it sees from disk (supply chain issue, like I posted)
I'm unconvinced. You're supposing an attacker that can compromise an OEM's imaging solution but not the (user configurable!) key store? That seems like an overly specific attack vector to me.
I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?)
If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.
systemd-boot can do that if you force it to (only does it by default on VMs cuz expectedly UEFI implementations in the wild are kinda shit)[1, 2]
[1]: https://www.freedesktop.org/software/systemd/man/latest/syst...
[2]: https://www.freedesktop.org/software/systemd/man/latest/load...
Sounds like browserchoice.eu but even more pointless. For the normies who don't care about what keys they want installed, it doesn't make a difference. For people who want to switch to linux, it also doesn't make a difference because unless they're setting up their computer for the first time, because the windows key would already be installed. The only thing it does is make setting up a new computer marginally easier for one specific case (ie. you want to install a non-windows operating system AND you don't want to dualboot), and ticks off a box for being "vendor agnostic" or whatever.
Right now to achieve that level of security you have to manually enroll only the keys you want. Have fun with that process.
There will still be the situation with microsoft signing third party bootloaders, because various legitimate system utilities (eg. the kaspersky rescue disk mentioned in the OP) will still need it, and telling users to clear their keys willy-nilly is just going to train users to blindly clear their keys whenever something goes wrong.
this is much more important than you realize.
Let's be clear here. Most computers ship with Windows pre-installed, thanks to Microsoft's exclusivity deals with OEMs and the general assumption of Windows as the default OS.
Most users, even those who want to use Linux exclusively, will never be able to utilize the first-OS-install functionality you propose, because the OEM will already have installed Windows on their behalf.
The end user wants to be able to just pick up a computer from Best Buy and have it work, out of the box.
Microsoft can't even conceptualize why you would want to run anything but the Windows that came with the machine. If the expected Windows kernel and files aren't there, or have been altered, that is evidence of malicious tampering—malware that must be stopped. (I'm deliberately steelmanning their perspective here.)
Streaming services want a secure content path. Game vendors want protection against cheating. In order to comply with local/regional/national laws, web sites need you to verify your age, and they need to know your computer is not lying (remote attestation). Nobody wants to be hacked.
The incentives for everyone else besides techies align against techies getting to run arbitrary code on their devices. The Secure Boot system is working precisely as designed.
Gamers, gamers want anti-cheats. Vendors couldn't care less.
> Vendors couldn't care less.
There are more than enough games that are designed around microtransactions that use grind and gambling mechanics to encourage spending. Throw bots and cheats at that and the entire thing breaks down.
The "user" and "hardware owner" are not necessarily the same person.
Every time I see someone campaigning to exercise their civil liberties via hardware or software, I wonder if their devices are connected to any network.
Because once you connect to a network, especially a WAN, your liberties are tempered by the rights of all other users.
If your device hosts malware, botnets, scammers, spammers, or other malicious activity, no you do not have a right to the liberty of your hardware. The network and the service providers have a fiduciary responsibility of harm reduction and threat mitigation.
Sure, some hackers are very very good at preventing malware and keeping the botnets at bay. You may be better at it than cloud providers or your ISP. In fact, it is the inexperienced users that we can't really trust. They'll get pwned and their browser will have a million toolbars with spyware. Their PC will join botnets and host CSAM. It is their ignorance and ineptitude that gets them into trouble.
And so because WANs, particularly the public Internet, are common property, and not your private domain or sandbox, this is why things like device trust and attestation are being added. Because you could do all you wanted with your Commodore 64 and your Apple ][. The blast radius was limited to your family and every friend who traded cracked software.
But once you're hooked up on a network, you need to stop swinging your fists at my nose.
This doesn't work for literally 99.9% of the users out there. This is a classic HN's Dropbox symptom.
You need overridable defaults.
The biggest weakness of secure boot was always third-party vendors shipping "insecure" bootloaders. It's a lot of work to verify signatures for every bit of data that gets loaded, especially on the PC platform.
Microsoft then made that system entirely useless by signing code that could be used to load unsigned code, like demonstrated here.
They then also refused to blacklist their own broken bootloader to save sysadmins the time (who would need to deploy new recovery images and boot media containing the fixed bootloader). That vulnerable bootloader is particularly bad because it can be used to have the TPM unlock itself and give up the Bitlocker key, which the Linux loaders shouldn'tbe capable of even if they apply the bypass mentioned in the article.
In a world where Microsoft cared about secure boot, they would blacklist the vulnerable Linux loaders as well as their own old bootloaders. Why Microsoft? Because they signed the files in the first place, only they can rescind the signatures. In that world, Linux users would call for Bill Gates' head for securing their security feature and sysadmins would be out for Steve Ballmer's blood for breaking their complex custom recovery system that nobody dares touch.
Now we'll be stuck in the worst of both worlds.
Source? The OP suggests they expect it to be blacklisted
>I assume that Kaspersky bootloader signature certificate will not live long, and it will be added to global UEFI certificate revocation list, which will be installed on computers running Windows 10 via Windows Update
If you search around you'll also find that microsoft does publish secure boot revocations, contrary to what you claim.
You might think the 2025 update will solve the problem, but:
> Before following these steps for applying the mitigations, install the Windows monthly servicing update released on July 8, 2025, or a later update on supported Windows devices. This update includes mitigations for CVE-2023-24932 but they are not enabled by default. All Windows devices should complete this step regardless of your plan to enable the mitigations.
The current status for the update (https://support.microsoft.com/en-us/topic/how-to-manage-the-...) says:
> The Enforcement Phase will not begin before January 2026, and we will give at least six months of advance warning in this article before this phase begins. When updates are released for the Enforcement Phase, they will include the following:
Basically, unless your company and sysadmin have enforced this fix (i.e. you're a home user), Microsoft hasn't revoked their keys.
Then there's CVE-2024-38058, a similar attack. Microsoft tried to roll out a fix, but that broke compatibility, and the fix was then rolled back. Again, that problem can be fixed with the solution for the previous CVE, but that is still not deployed by default.
https://neodyme.io/en/blog/bitlocker_screwed_without_a_screw... describes the TPM2 attack in detail as well as mitigations and solutions much better than I can.
>For instance if your iPhone is infected with malware
Then restarting it will remove it. So far Apple has had a perfect record with this unlike Android.
Not things like Pegasus.
It does not minimise attack surface, but minimise ways _you_ can ensure there is nothing on the phone that shouldn't be there.
Normalizing "security" software running in the background to "scan" things has proven a social and technical disaster. Users think it's normal to have such activity (and receive random "virus alerts"), leading to over two decades of social engineering scams, fraud, and malware-delivery. On top of that, "security" software has a habit of creating its own security holes and problems. Look at game anti-cheats (one was just on the front page the other day), the CrowdStrike incident, etc.
OS vendors should simply deliver a secure OS. That isn't easy, but it's still easier and more reliable than shipping third-party "security" software after the fact.
A platform where compromise is, by design, undetectable to the owner is not “more secure”, it’s merely less observable. That’s security through opacity, not security through design.
Yes, third-party security software has a bad history. So does third-party everything. That doesn’t magically make a closed system safer. It just moves all trust to a single vendor, removes independent validation, and ensures that when something slips through, only the platform owner gets to decide whether it exists.
“The OS vendor should deliver a secure OS” is an aspiration, not an argument. No OS is bug-free. Defence in depth means independent mechanisms of inspection, not just a promise that the walls are high enough.
Apple’s model works well for reducing mass-market malware and user error. It does not work for high-assurance trust, because you cannot verify state. If you can’t audit, you can’t prove clean. You can only assume.
That may be a perfectly acceptable trade-off. But let’s not pretend it’s the same thing as stronger security. It’s a different philosophy, and it comes with real blind spots - which to some people make Apple devices a non-starter.
The way things are headed, it's getting hard to trust the people in Apple's metaphorical cockpit.
Is this really true, in 2019 when this was written or today? I haven’t seen a motherboard that didn’t let me enroll my own keys in a really long time. Laptops are a different story but even there, it’s been awhile.
> Microsoft forbid to sign software licensed under GPLv3 because of tivoization restriction license rule
Ah yes, GPLv3 is now Microsoft’s fault?
This is true in the sense that they only ship with MS' keys as trusted, but all MoBos (including laptops) I had allow enrolling your own. Some might handle not having MS' keys better (or at all) than others, but it should in theory be possible to remove them, whether it will boot after is a different question (see option-ROM [1])
You are missing the point. It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs.
So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft.
Let's not forget that we're talking about the company responsible for Windows 11 here.
Of the GPLv3 sentence? No, it's dishonest rhetorically. Of the piece? Also I don't think so, exploiting the shims is a fun way to prove that Secure Boot is silly but we already knew that, and by 2019 claiming that "most" systems only allowed Microsoft keys is just flat out dishonest as well.
> It's the fault of those who pushed SecureBoot down our throats (and don't get me wrong: I use SecureBoot) to have decided that Microsoft had both a free-pass to have its certs by default in every UEFI out there but no other certs.
I really don't get this argument in general; Microsoft certs are enrolled by default as a combination of: a matter of convenience for majority users who are going to use Microsoft OSes, the unfortunate design of Option ROM signature checking, and the desire to get a Windows logo on the packaging and Microsoft OEM discounts.
There's no Secure Boot or UEFI related reason that boards can't come in Setup Mode with no PK, and most industrial boards do indeed come this way, since they don't need Option ROMs and customers don't want a Microsoft logo.
> So users either have to understand how to enroll their own certs or to use a shim signed by... Microsoft.
This seems like the best outcome for end-user computers which will have Windows installed to me? Users get a computer that checks that the OS it came with is valid (well, tries to, but that's a different can of worms), and still have the option to do whatever they want with it if they so desire. They can choose the Microsoft signed shim for convenient dual-booting, or erase the platform keys and own their system end to end if they wish.
> Let's not forget that we're talking about the company responsible for Windows 11 here.
I've never really understood these arguments, and it's even weirder to bring Windows 11 into it. Is the thing we're railing against here Ballmer-Borg Microsoft? Shitty Product Management Kills Products Microsoft? AI Infested Microsoft? The Venn diagram of overlap between 1990s Microsoft (genesis of UEFI), 2012 Microsoft (Secure Boot introduction), and 2025 Microsoft (Windows 11) seems likely to be... quite small.
No that it bothers me all that much either way.
There was also a Western paper on embedding hidden circuits (and thus functionality/ISAs) into CPUs and activating them in the field (after deployment) by executing a sequence of opcodes resulting in something akin to blowing a fuse on the processor die, thereby making the circuits invisible (to even a microscope) until activated. Those secret opcodes could then disable the chip or jump into a block of secret microcode and alter the program counter to behave in a non-standard manner so we might not easily be able to see what's happening, even if we knew to look. One still would have to deliver that secret sequence of opcodes to trigger such a stealth mode...that could be done via microcode/firmware updates from the manufacturer's website or an OS update, or similar techniques. Interestingly, an unexpected iteration of Chinese SoCs began flooding the markets just as the rest of the World was sustaining a "chip shortage" in a timeframe perfectly aligned with what would have been required to implement such a system after that paper was published.
Air-gapping the customer's devices during installation (to prevent the activation opcode sequence) might not work either. Many Chinese SoCs are used as embedded peripherals simply to add WiFi, Bluetooth and Thread capabilities onto existing designs via a simple UART or doorbell interconnect. This makes it too easy for these Chinese SoCs to also be listening for a Morse-code-like activation signal on a low-frequency band, triggering the backdoor to open (enabling a more conventional remote code execution port or logic debugger exposed via WiFi or BLE for example, or causing malfunction or damage to what's on the GPIO or UART pins). Such low-frequencies could be disguised (think Blue Whale signals) so they might be sent slowly over great distances (or even from floating weather balloons or low earth orbit) without drawing too much suspicion. https://youtu.be/E-gbYjLd93g
The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
This conspiracy was never true and never happened. First off, note that the first version of the thing in the article you’re commenting on relied on a Fedora shim loader which Microsoft signed. Second off, note that almost all modern motherboards let you enroll your own UEFI keys and do not rely on exclusively the Microsoft keys.
The only place this is was becoming an issue for Linux was early Secure Boot implementations where the vendor was too lazy to allow key enrollment, and that era has generally passed.
Even just the lies around required hw updates is enough not to trust them.
SecureBoot looks like a system designed to make it hard to change OS, it has been used by MS for that, MS have a history of user-antagonist actions.
You say the conspiracy was never true, I'm going to need some serious proof.
To be fair SecureBoot is in a way just that: it is intended to only boot binaries that are signed with a key that has been enrolled into the UEFI. The main issue is like almost always how those keys are managed.
Business class computers (Thinkpads, Latitudes or Elitebooks) have somewhat half-assed firmware. So you usually don't encounter shenanigans like that.
Only server computers have almost not half-assed firmware. They are very reliable but take forever to boot.
If you want non-half-assed firmware, found your own computer company or join big tech where they can afford custom motherboards with their own firmware.
Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.
It’s generally a lot more secure to avoid the use of any shims (since they leave you vulnerable to what happened in this article) and just build a UEFI Kernel Image and sign that.
Some systems need third party firmware to reach the OS, and this can get a bit more complicated since those modules need to load with the new user keys, but overall what you are asking is generally possible.
examples and documentation welcome
Technically yes, with a massive fucking asterisk: Some option-ROM are signed with the MS certs and if your Motherboard doesn't support not loading those (whether needed or not) you will not be able to sometimes even POST.
SecureBoot exists on servers too. And that's the domain of Linux, not Windows.
Microsoft should never have had so much influence in SecureBoot but there's no way they're getting rid of Linux on servers. Microsoft is mostly irrelevant there.
> The continued Linux desktop solely relies on antivirus vendors writing crappy insecure software. So we'll be fine forever.
That's also a weird take. It's antivirus vendors who are going to be fine forever: they rely on Microsoft to write crappy insecure software. And that is a given.