Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Damn Vulnerable UEFI

github.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Damn Vulnerable UEFI

#31

Post by crabbone »

AnthonyMouse wrote: post #14
harshreality wrote: post #10

Earlier quoted context omitted.

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot? Granted, most of what goes on in a BIOS is displaying an…

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper…

Absolutely this.

Not sure which article that complained about EFI mentioned that PNG parser was vulnerable... and... there's no reason for EFI to have a PNG parser really. It's a fancy stuff that could've been totally avoided. And yet, here we go...

Re: Damn Vulnerable UEFI

#32

Post by kokada »

blueflow wrote: post #28
kokada wrote: post #24

Earlier quoted context omitted.

Yes, UEFI is messy, not saying you will never have issues. But on the other hand, in OpenWRT you literally need to build an image for each device, something that you (almost) never have to do with UEFI or BIOS. Or when was the last time you had to build a specific image for a x86_64 laptop? If this happened to you, I am curious, this would probably make a nice blog post. By the way, I am not saying that UEFI is not c…

> Or when was the last time you had to build a specific image for a x86_64 laptop? iwlwifi firmware blobs..

This isn't related to UEFI itself though.

Re: Damn Vulnerable UEFI

#33

Post by p_l »

hulitu wrote: post #29
p_l wrote: post #23

Earlier quoted context omitted.

TL;DR UEFI builds an open platform even if the actual code is closed, while "simple" alternatives make closed platforms with open source code. Raw coreboot/uboot like approaches give you open source but closed platform - the simplicity means you need considerable resources to do something else than the original maker wanted to do with it. UEFI (and before it, Microsoft attempts at semi-standardizing PC low level inte…

> Did I mention how much easier handling booting with UEFI is compared to unholy mess of most other systems? Yeah. Like linux entries getting ignored, no eay to debug what went wrong (if an EFI executable fails, you're on your own). A shell which is undocumented. With BIOS i didn't spent hours trying to boot a linux kernel.

Unless you encountered a BIOS that actually followed the spec instead of blindly loaded a sector and hoped for the best, and learnt that your typical linux install programs made malformed MBR that does not mark the drive as bootable so BIOS actually should skip it when booting.

Or when grub suddenly stops working on a dual boot system, and after you fix it another part on the non linux system fails, and if you fix that grub fails (and fails in all cases hard enough you need to boot from something else). After some time you either ended up dropping either grub or $some_important_software - poor you if the latter is something you make money to sustain yourself. All because, surprise, you're not supposed to write bootloader code into cylinder 0 outside of first sector, and various signature systems used in licensing use the no-mans-land of cylinder 0 to scribble signatures.

BIOS offered even less debug tools than (U)EFI, so dunno what you're talking about. UEFI shell is documented, if not as well as it could be, and even has built-in help. That you can, worst case, boot it (or any other tools) from simple fat32 formatted pendrive that can be created with a file manager instead of rawdogging the hard disk is just a bonus.

The cases with Linux entries being ignored were plain bugs by specific manufacturers, bugs that also hit windows (because the vendors in question worried that them not checking properly would backfire, and instead of checking the firmware properly hardcoded few tested bootvar names).

And the ignored entries could be resolved by using standard fallback bootloader paths, or renaming linux entries to same as ones that work.

Re: Damn Vulnerable UEFI

#34

Post by blueflow »

kokada wrote: post #32
blueflow wrote: post #28

Earlier quoted context omitted.

> Or when was the last time you had to build a specific image for a x86_64 laptop? iwlwifi firmware blobs..

This isn't related to UEFI itself though.

Not directly, but making bootable images is much easier if your firmware is stateless and does not require setup with efibootmgr.

Re: Damn Vulnerable UEFI

#35

Post by sounds »

p_l wrote: post #26
TacticalCoder wrote: post #22

Earlier quoted context omitted.

> It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface. By design. The UEFI is a gigantic NSA backdoor. I've got a bridge to sell to anyone who believes the NSA doesn't own the Microsoft UEFI signing keys, for a start.

It not being a backdoor and NSA stealing UEFI keys from MS aren't exclusive. To the point that it's Microsoft who mandated a deviation from UEFI SecureBoot spec that enables owners to replace root of trust keys (Platform Key) in UEFI systems if the vendors wants that "designed for windows" sticker.

Microsoft only mandated that for the "designed for windows" sticker, while simultaneously mandating that their arm laptops went hard in the opposite direction. https://news.ycombinator.com/item?id=3458679

Re: Damn Vulnerable UEFI

#36

Post by p_l »

sounds wrote: post #35
p_l wrote: post #26

Earlier quoted context omitted.

It not being a backdoor and NSA stealing UEFI keys from MS aren't exclusive. To the point that it's Microsoft who mandated a deviation from UEFI SecureBoot spec that enables owners to replace root of trust keys (Platform Key) in UEFI systems if the vendors wants that "designed for windows" sticker.

Microsoft only mandated that for the "designed for windows" sticker, while simultaneously mandating that their arm laptops went hard in the opposite direction. https://news.ycombinator.com/item?id=3458679

That was during MS early flirting with ARM based devices running normal windows kernel.

The "setup your own PK without vendor or even Microsoft keys" is part of Microsoft's offering for some big dollar clients in Enterprise, which is why it's included in certification these days.

And I mean using your own keys, not running without SecureBoot, which was the topic linked in the 2012 discussion.

Re: Damn Vulnerable UEFI

#37

Post by sounds »

p_l wrote: post #36
sounds wrote: post #35

Earlier quoted context omitted.

Microsoft only mandated that for the "designed for windows" sticker, while simultaneously mandating that their arm laptops went hard in the opposite direction. https://news.ycombinator.com/item?id=3458679

That was during MS early flirting with ARM based devices running normal windows kernel. The "setup your own PK without vendor or even Microsoft keys" is part of Microsoft's offering for some big dollar clients in Enterprise, which is why it's included in certification these days. And I mean using your own keys, not running without SecureBoot, which was the topic linked in the 2012 discussion.

I think you're intentionally obscuring the difference between:

(1) A system locked by Microsoft, who benevolently allows some users to achieve freedom by setting up new Platform Keys.

If the big dollar clients demand standardization and openness, then it might curtail the typical Microsoft antitrust shenanigans.

(2) A system that is owned by the purchaser, who may choose to deploy Microsoft or other security solutions, and then remove them, at will.

We already have (2), so any attempt to subvert it is by definition untrustworthy.

Item (1) is what is called "trustworthy computing," and Microsoft still openly celebrates it [1].

Item (2) is what is being obscured.

[1] https://www.microsoft.com/en-us/security/blog/2022/01/21/cel...

Re: Damn Vulnerable UEFI

#38

Post by Terr_ »

AnthonyMouse wrote: post #14
harshreality wrote: post #10

Earlier quoted context omitted.

How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot? Granted, most of what goes on in a BIOS is displaying an…

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper…

> none of which need a mouse

Heh, I'm having flashbacks to a time repairing a computer where the BIOS/UEFI simply wouldn't work work with the regular keyboard, even though the regular OS supported it just fine.

So I had to go dig up a PS/2 one just to change settings.

Re: Damn Vulnerable UEFI

#39

Post by p_l »

sounds wrote: post #37
p_l wrote: post #36

Earlier quoted context omitted.

That was during MS early flirting with ARM based devices running normal windows kernel. The "setup your own PK without vendor or even Microsoft keys" is part of Microsoft's offering for some big dollar clients in Enterprise, which is why it's included in certification these days. And I mean using your own keys, not running without SecureBoot, which was the topic linked in the 2012 discussion.

I think you're intentionally obscuring the difference between: (1) A system locked by Microsoft, who benevolently allows some users to achieve freedom by setting up new Platform Keys. If the big dollar clients demand standardization and openness, then it might curtail the typical Microsoft antitrust shenanigans. (2) A system that is owned by the purchaser, who may choose to deploy Microsoft or other security solution…

I think you are intentionally obscuring the difference between "no standard solution for cryptographic check of what you're booting" and "solution that provides that which one of the vendors pushed to make switchable in ways that keep it open for others as well, even if only because it makes business sense for them as well"

Trustworthy computing, even in Microsoft way, involves owner deciding what's running and being able to verify that. Funnily enough Microsoft's "solution" here involves removing Microsoft keys and owner signing specific binaries they allow to run.

We don't have yours (2) because of various gaps you could drive an American freight train through. The options that exists are all even more closed down than SecureBoot (which is just one leg of Trustworthy Computing).

N.B. the main subversive component in all of this, and tellingly implemented because stakeholders of "trustworthy computing" actually care about owner control, is protected media path, foisted by MPAA and streaming industry through closed blobs in Intel ME and AMD PSP

Re: Damn Vulnerable UEFI

#40

Post by AnthonyMouse »

pixl97 wrote: post #18
AnthonyMouse wrote: post #14

Earlier quoted context omitted.

> How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper…

And when you don't have an OS because you need to update the flash first?

You don't need to update the flash to boot an OS capable of updating the flash. The firmware it comes with can do that and if you've irrecoverably installed broken firmware then you've bricked your machine regardless.
Post reply on HN