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

21–30 of 142 posts

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

#21

Post by mschuster91 »

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…

> The problem here is that the signature doesn't do anything for you.

For your own personal machine, sure. But say you're a sysadmin in a company that has thousands of units. Suddenly, a CA infrastructure is much more appealing than having to deal with component hashes.

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

#22

Post by dietr1ch »

1oooqooq wrote: post #14
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

My first encounter with UEFI turned out to be quite expensive because UEFI was way too new and easy to brick. I guess things are better now, but toying around with this might still be a risk not worth taking as a consumer.

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

#23

Post by getcrunk »

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.

Yea but when things like this keep happening … it becomes a pattern. A very convenient one at that.

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

#24

Post by getcrunk »

fsflover wrote: post #8

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

What hardware do you use the most recent supported seems like the Librem offerings. Which are intel 10th gen. Otherwise it’s gets pretty ancient

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

#25

Post by coderatlarge »

scraptor wrote: post #17
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.

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?

> When's the last time you made a motherboard purchase decision on the basis of firmware quality?

i would argue every apple macbook purchase implicitly includes this.

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

#26

Post by db48x »

scraptor wrote: post #17
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.

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?

At the Internet Archive we occasionally had to return big batches of hard drives because of firmware bugs. That had to have ruined someone’s day, but apparently not enough to actually level up their engineering so that it wouldn’t happen again.

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

#27

Post by db48x »

neilv wrote: post #20
db48x wrote: post #13

Earlier quoted context omitted.

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

All of that sounds very plausible to me.

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

#28

Post by Lammy »

gruez wrote: post #12
jerhewet wrote: post #10

Please ... just give me back my BIOS.

BIOS isn't magically secure either. It has no secureboot so it just runs whatever.

I refuse to endorse any mindset where my Personal Computer unquestionably running my code could be considered a bad thing.

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

#29

Post by wmf »

bradfa wrote: post #18
db48x wrote: post #13

Earlier quoted context omitted.

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…

I think you could get AGESA and combine it with EDK2 yourself; it's just person-years of work.

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

#30

Post by gruez »

Lammy wrote: post #28
gruez wrote: post #12

Earlier quoted context omitted.

BIOS isn't magically secure either. It has no secureboot so it just runs whatever.

I refuse to endorse any mindset where my Personal Computer unquestionably running my code could be considered a bad thing.

You're conflating UEFI with secureboot. Moreover all the secureboot implementations I've seen allow you to either disable it or enroll your own keys.
Post reply on HN