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

Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

binarly.io

Post reply on HN
Print view View original

11–20 of 142 posts

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#11

Post by EPWN3D »

OjotCewIo wrote: post #7
db48x wrote: post #3

> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.

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.

They're not. They're ravaged by probably the same quality or slightly higher than average. The cost of mistakes is just way higher.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#13

Post by db48x »

OjotCewIo wrote: post #7
db48x wrote: post #3

> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.

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.

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.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#14

Post by 1oooqooq »

fsflover wrote: post #8

Fortunately there's a FLOSS alternative: TPM with Heads, https://osresearch.net/ . Works for me.

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

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#15

Post by ahepp »

candiddevmike wrote: post #6
db48x wrote: post #3

> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.

This is all too common with any kind of user infantilizing security feature. Trust us bro, it's secure.

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.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#16

Post by AnthonyMouse »

ahepp wrote: post #15
candiddevmike wrote: post #6

Earlier quoted context omitted.

This is all too common with any kind of user infantilizing security feature. Trust us bro, it's secure.

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 gar…

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.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#17

Post by scraptor »

OjotCewIo wrote: post #7
db48x wrote: post #3

> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.

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.

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?

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#18

Post by bradfa »

db48x wrote: post #13
OjotCewIo wrote: post #7

Earlier quoted context omitted.

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.

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.

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.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#19

Post by gruez »

AnthonyMouse wrote: post #16
ahepp wrote: post #15

Earlier quoted context omitted.

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 gar…

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…

>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.

What if you need to update the bootloader?

>The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else.

TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. It'd be clumsy, but doable, just like your idea of using hashes for verification.

Re: Another Crack in the Chain of Trust: Uncovering (Yet Another) Secure Boot Bypass

#20

Post by neilv »

db48x wrote: post #13
OjotCewIo wrote: post #7

Earlier quoted context omitted.

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.

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.

> 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?

Post reply on HN