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

61–70 of 142 posts

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

#61

Post by josefx »

necovek wrote: post #38
jrm4 wrote: post #31

I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.

It's mostly about your UEFI firmware coming with a set of trusted CAs to verify bootloader is built by one of the trusted parties like Microsoft or Canonical or Redhat or... You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.

Unless the software vendor requires it to be locked down hard. Microsofts certification requirements for ARM devices back in 2012 explicitly required secure boot and prohibited custom certificates.

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

#62

Post by mjg59 »

AnthonyMouse wrote: post #34
gruez wrote: post #19

Earlier quoted context omitted.

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

> What if you need to update the bootloader? Then you boot the system from the existing bootloader, causing the booted system to be trusted to supply a new hash. > TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. If there are no private keys in the TPM from the factory then there is nothing for a third party to force you to sign the hash with, as intended.

How does the system know whether the new bootloader is legitimate or not?

All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys.

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

#63

Post by mjg59 »

AnthonyMouse wrote: post #35
mschuster91 wrote: post #21

Earlier quoted context omitted.

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

How is it any different? You install the hash of the boot loader when you issue the machine, then use the trusted system to update the hash if necessary. Also, the concern is that the system comes from the factory with private keys the owner doesn't have access to, allowing the device to defect by informing on them to a third party. Keys installed by the owner rather than the manufacturer are fine, and then such keys…

If a device is running code you control, how does it defect?

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

#64

Post by bradfa »

wmf wrote: post #29
bradfa wrote: post #18

Earlier quoted context omitted.

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.

Unfortunately it’s not quite that simple. Yes you can likely get AGESA but there is a whole bunch of other code you’d still have to write yourself and it’s not trivial without quite a few documents that AMD is unlikely to give you even with normal NDAs.

Now, Intel platforms you maybe have a shot at using EDK2 on, especially those with FSP. But Intel is unlikely to give you any support when something goes wrong and there’s probably no way to pay Intel to change that unless you’re a very big customer.

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

#65

Post by miki123211 »

lmm wrote: post #43
jrm4 wrote: post #31

I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.

Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.

I suspect the actual reason is a lot more banal, it's enterprises asking for it.

People who own fleets of devices and need to keep them secure don't care about homegrown Linux distributions, they want to minimize the fallout from that one employee installing the "FlashPlayer update" again. Those are the people driving the concerns of Microsoft and computer vendors.

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

#66

Post by miki123211 »

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…

It's not a point of competition, plain and simple.

Better software doesn't sell more hardware. From those companies' point of view, what matters is hardware features to make consumers want the product, and manufacturing efficiency to make margins high. The quality of what's in the ROM is no more important than the quality of the fans, servos, DACs or what have you. As long as the parts don't break too often and are within specifications, they're good enough, no point in wasting money to make them better.

This, of course, is true until it isn't. At some point, somebody comes along who disrupts the space completely by making the software great and well integrated (or just by making it do what people have previously had to do in hardware), and traditional companies don't know how to cope.

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

#67

Post by heavyset_go »

jrm4 wrote: post #31

I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.

Stick a BIOS password on your machine and turn on Secure Boot.

Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc.

You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered.

Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run.

This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.

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

#68

Post by Y_Y »

HPsquared wrote: post #55
lmm wrote: post #43

Earlier quoted context omitted.

Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.

With laptops, unauthorized physical access happens a lot more often. People lose them, they get stolen, etc.

Presumably drive encryption is necessary anyway to protect lost/stolen devices, and at that point modifying the bootloader won't be useful.

I see the value when the attacker manages to modify the device without the user knowing, and causes them to unknowingly use an attacker-controlled OS, but that's a vastly different threat model.

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

#69

Post by autoexec »

FirmwareBurner wrote: post #41
jrm4 wrote: post #31

I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. I own a piece of hardware, so I can do what I want to it. Out there, there is software, which I have to figure out how I'm going to trust, whether it's e.g Windows and I'm trusting that whole way of doing things, or Linux and that other whole way of doing things.

>I own a piece of hardware, so I can do what I want to it. It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other potential bad actors.

Then why force it into consumer hardware? If it were only available on enterprise servers nobody would care.

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

#70

Post by Y_Y »

tom1337 wrote: post #49
mjg59 wrote: post #48

Earlier quoted context omitted.

Which vendors?

As example, FaceIT Anti Cheat only works if Secure Boot is enabled. I guess their argument is that they can ensure you only boot genuine Windows and thus they can better check if you've tampered with anything.

https://www.theguardian.com/technology/blog/2006/jul/14/wind...

I see Microsoft's malicious erosion of the meaning of "genuine" is going well.

Post reply on HN