What makes you think that? Secure Boot prevents this rootkit from running and is the recommended mitigation:
> Bootkitty is signed by a self-signed certificate, thus is not capable of running on systems with UEFI Secure Boot enabled unless the attackers certificates have been installed.
> To keep your Linux systems safe from such threats, make sure that UEFI Secure Boot is enabled
In fairness, the blog post confusingly says this in the next bullet point:
> Bootkitty is designed to boot the Linux kernel seamlessly, whether UEFI Secure Boot is enabled or not, as it patches, in memory, the necessary functions responsible for integrity verification before GRUB is executed.
However, this would still require Rootkitty to have gained execution already, which it wouldn't be able to if Secure Boot was enabled and the malicious actor's certificates weren't installed.
Hello, I am the Bootkitty developer. The reason our bootkit is self-signed is because it uses the LogoFAIL vulnerability to register a MOK on the system to bypass secureboot, which is why our signature is included. I will leave an analysis article about LogoFAIL at the link below.
https://www.binarly.io/blog/logofail-exploited-to-deploy-boo...
Secure boot prevents this proof of concept but it doesn't prevent all UEFI boot kits and this particular kit will likely evolve.
On window: It took several years until the first two real UEFI bootkits were discovered in the wild (ESPecter, 2021 ESET; FinSpy bootkit, 2021 Kaspersky), and it took two more years until the infamous BlackLotus – the first UEFI bootkit capable of bypassing UEFI Secure Boot on up-to-date systems – appeared (2023, ESET).
It was just a way for Microsoft's partners to limit the ease with which one can install alternative OSes. Try explaining to your mother how to disable SecureBoot to install Ubuntu. It used to be a single sentence - pop the CD in and follow the instructions, but Microsoft couldn't have that. As is always the case with Microsoft, security is never the goal unless they gain a competitive advantage or make it harder for their customers to move away in the process.
"It was just to keep people from installing something other than Windows" seems very counter-indicated by it taking ~7 years for a Windows UEFI bootkit to come out, and 13 years for one for Linux.
...and this bootkit is not able to work if Secure Boot is set up.
UEFI is also a godsend in terms of fixing a lot of the legacy BIOS crap
And my bloody computer is potentially trying to make god-blessed network calls before the OS has even loaded, and before my machine even provides the bare minimum human interface, you want me to navigate cryptography?
The trusted computing initiative was a disaster to the learnability of the computing field.
Devs are users too. Especially the unskilled/ignorant ones.
It is a mixed blessing, the ever-upward bass of complexity.
Most people are probably glad that their computers have guis and they can install applications with just a few clicks. The price of those features is complexity.
Ultimately, we're all like the Amish: we make decisions about our preferred level of technology. I won't have a smart TV in my house, but I'm happy to have UEFI systems.
You only need disable it until you've got that OS installed, and then you can re-enable it. All the major linux distros have supported Secure Boot for years (which I was not aware of, and will now look into setting up!)
Most distros will run just fine without disabling secure boot. I don't think the *BSDs are supported by the shim loader yet, but even Gentoo boots with secure boot enabled, without loading any user keys.
Because it can lock the door behind itself in an opaque hardware-dependent layer users have no control over.
If i were to design security from the ground up it would be a small external sdcard for firmware and kernel (with a hardware r/w toggle), and optionally a external sdcard adapter that verifies the hash of the content.
Everything else is as dumb as bricks and gets its firmware loaded from the sdcard.
We didn't do that because secure boot was solving the problem of large orgs with remote administration in mind, and designed by orgs happy to sell yearly advanced cybersecurity protection shield plus certification subscriptions.
Designing for remote administration by an IT department will.. increase the attack surface for attackers to remote administrate my device.
Is the implication that anything that is more complicated is necessarily less secure? Because I think that turns security on its head. A deadbolt is more complicated than a door with no lock.
We can argue about whether there is sufficient user demand and benefit to make secure boot easier for lay people. But that is completely orthogonal to whether it increases or decreases security of the system.
and identity. most of the world now replaced your credit card and government id with apps that rely on the OS assurences to prove you're yourself with vendor keys, mandatory selfies and such.
I agree the move to UEFI added a huge new attack surface and that most UEFI implementations (notably, even the open source ones) are teeming with horrible bugs.
And yes, then linking the trust architecture for Secure Boot so deeply with UEFI means that UEFI bugs are also Secure Boot bugs.
But to say this is less secure? No way. Traditional BIOS-based MBR backdoors are like 1980s oldschool classic stuff. Most adversaries would require a good degree of development work to backdoor / root kit a PC they were given with Linux, Secure Boot, and an encrypted filesystem. With a BIOS based PC there would literally be nothing to do.
I think UEFI has many problems. However, you should not confuse separate (but related) issues from each other. If the initial booting functions can be altered by the operating system, that is a different issue (which perhaps UEFI makes it more severe). An internal hardware switch to disable this function would be helpful, and possibly a software function that the BIOS disables once the system starts (so it can only be altered by the BIOS setting menu, or by a BASIC or Forth in ROM or something like that). Functions being restricted by internal hardware switches would improve security, especially if also the initial booting functions are made less complicated too; if you are paranoid then you could also use glitter or whatever to detect hardware tampering.
> An internal hardware switch to disable this function would be helpful
For desktops and mobos, maybe. Gonna be hard to make that work for laptops and phones.
But generally I'm in agreement. By the time I'm booting into and using the system the BIOS is no longer a discussion point; if I need to update it then I need to shut it down and get under the hood.
UEFI itself is way too complex, has way too much surface (I'm surprised this didn't abuse some poorly written SMI handler), and provides too little value to exist. Secure boot then goes on to treat that place as a root of trust, which is security architecture mistake, but works ok in this case. This all could be a lot better.
I cannot help but think the move to UEFI and Secure Boot made things less secure :(