UEFI shell vulnerabilities allow attackers to bypass Secure Boot
eclypsium.comIf stuff like the Raptor Talos can exist, surely the community can come together to support a company building an x86-64 motherboard that is completely binary-blob free...
The UEFI shells are generally built from open source upstream code. IMO the real issue is that there is something quite wrong with a security model that thinks it’s a problem that someone can run a UEFI shell and modify memory but does not consider it a problem that one can boot their favorite Windows or Linux kernel and act as LocalSystem or root.
There is a very, very good reason we don't have homebrew x86 boards. They're incredibly difficult and expensive to design, produce, and verify. Modern hardware has crazy high clock rates and even tighter timing tolerances. Beyond that, you have to convince whichever OEM to sell you the chipset in small quantities. And then you have to write miles of drivers and firmware and a BIOS.
And then you need to acquire and test every combination of CPU and RAM that any customer might conceivably use, then patch your miles of firmware to support each chip.
Oh and also you have to ensure your firmware can never, ever fail in such a way that cuts off fans or cranks up CPU voltage.
It's an incredibly involved process, which is why only big companies have the resources to pull it off. It's not impossible for a community board to be made, but it's something that would take years of work and a lot of money.
But don't most of the design issues apply to Talos as well?
And if it's security focussed, I think it's acceptable to say "It's AM4 (not 5), and only works with this RAM brand with these times and costs 5 times as much". It's a niche, and when people are into a niche they take the tradeoffs they get.
there are a bunch of presentations from Bryan Cantrill of Oxide computing explaining why this is difficult to do.
Secure Boot is not something that should be part of a consumer computer at all, in my opinion. Enterprises might have some use for it, but for a consumer who wants to be able to do anything they want with their computer, it doesn't make sense.
I am a consumer who is concerned about evil maid attacks and consider secure boot a good solution for this problem. I don't understand why this "doesn't make sense".
Secure boot never stopped me from doing anything I wanted with my hardware.
> I am a consumer who is concerned about evil maid attacks and consider secure boot a good solution for this problem. I don't understand why this "doesn't make sense".
Physical access ? Like putting an oscilloscope on your cpu bus ?
> I am a consumer who is concerned about evil maid attacks
This is seriously the least likely way for you to be hacked. Much more likely is that an auto-update is downloaded and run from a hacked server, or you sometimes use pip/npm/etc to install dependencies for some software project and get malware that way, or you get tricked into opening a zipped document in an email that ends up having executable code because industry-standard doc viewers and OSes try to be too smart ...
> Secure boot never stopped me from doing anything I wanted with my hardware.
But, you may have done a lot of things that it should have stopped you from doing. For 5 to 10 years a bunch of utilites for monitoring temperatures and fan speeds and controlling RGB lighting etc have used the signed "winring0" driver to be able to poke arbitrary hardware registers of various chips over various low-level busses (i2c etc), just a couple months ago this "winring0" driver was blacklisted, identified as malware, and quarantined by Windows Defender. There's other solutions that these tools have shifted to, like "PawnIO" and custom signed drivers.
On the topic of Framework, you can use "ectool" to control fan behavior and charging behavior etc of the environmental controller chip, but for many years you had to disable secure-boot for this thing to be able to poke that chip. About a year ago I recall a forum conversation where someone was intent on porting this tool to use winring0 on windows so that they did not have to "endanger" their system by disabling secure-boot. I really didn't think there was any point, because if winring0 lets you bypass protections that secure-boot relies on, it's just a big charade.
Many signed third-party windows drivers have been found vulnerable to enabling arbitrary memory poking somehow, which theoretically lets you bypass any protections that secure-boot intends to provide. They eventually get updated and old versions blacklisted, but there's always a bunch and there's always more. And remember Logo-Fail? Letting people update the boot logo, without re-signing with their own key loaded into their system?
And if we look at the other discoveries by Eclypsium, the theme here is debug and repair tools. Do you want debug and repair tools to be allowed without disabling secure-boot?
It turns out that lots of people, maybe most people, expect to be able to do things with their laptop, which secure-boot really shouldn't allow. For practical reasons we tend to just go ahead and get that signed with some Microsoft key and allow it. There's a real theater to thinking secure-boot is super important and you're super-secure, while expecting and depending on functionality which really means that secure-boot has been compromised in 100 different ways. I just turn it off, it just makes things more complicated.
Secure boot-enabled devices allow you to do anything you want, even enrolling your own keys. What's stopping you from doing that?
There is no technical requirement for Secure boot to allow enrolling your own keys. Also, have you ever actually tried to enroll your own keys? The process for each and every board is basically unique
Theoretically nothing, but there's even less stopping me from turning it off instead
Secure boot greatly increases computer security for everyone.
> Secure boot greatly increases computer security for everyone.
Citation needed. /s
You do realize that Secure boot is mostly pushed by Microsoft, which has a terrible security.
ALL of the major hyperscalers use a version of secure boot. It would be insane not to.
> UEFI-level anti-cheat bypasses
Anyone have a hash? I would love to reverse engineer one of these.
The article's title unfortunately makes it sound like this is a problem unique to Framework laptops.
However, they do mention in the article that "this situation is not unique to Framework"
I really admire what Framework has been trying to build. Glad that they were able to fix this issue promptly!
I really love their hardware (13" 11th gen is my rig), imagine if they made a phone!
Thanks - we've changed the title to the subtitle above