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

71–80 of 142 posts

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

#71

Post by fsflover »

heavyset_go wrote: post #67
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 fro…

> you are now secure against petty criminals stealing your data

Ordinary disk encryption would protect me too here, wouldn't it?

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

#72

Post by HPsquared »

Y_Y wrote: post #68
HPsquared wrote: post #55

Earlier quoted context omitted.

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.

Some kind of secure enclave is necessary to prevent brute force attacks. Allows simple PIN unlock for users.

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

#73

Post by quotemstr »

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.

> Why is it that the most security-sensitive areas are ravaged by the sloppiest programmers and the most negligent managers and business types?

Lemon market: https://www.sfu.ca/~wainwrig/Econ400/akerlof.pdf

Buyers can't distinguish good work from bad, so they pay only average price and thereby drive out the high-quality sellers.

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

#74

Post by npteljes »

fsflover wrote: post #71
heavyset_go wrote: post #67

Earlier quoted context omitted.

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

> you are now secure against petty criminals stealing your data Ordinary disk encryption would protect me too here, wouldn't it?

I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk.

https://security.stackexchange.com/questions/267222/full-dis...

So, there are two scenarios here.

First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe.

Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.

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

#75

Post by fsflover »

npteljes wrote: post #74
fsflover wrote: post #71

Earlier quoted context omitted.

> you are now secure against petty criminals stealing your data Ordinary disk encryption would protect me too here, wouldn't it?

I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk. https://security.stackexchange.com/questions/267222/full-dis... So, there are two scenarios here. First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe. Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootload…

The second case requires a professional, dedicated attacker. I use TPM with Heads and a hardware key to protect myself against it. It will notify me if the boot partition or BIOS are tampered with.

As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.

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

#76

Post by lmm »

HPsquared wrote: post #72
Y_Y wrote: post #68

Earlier quoted context omitted.

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.

Some kind of secure enclave is necessary to prevent brute force attacks. Allows simple PIN unlock for users.

> Some kind of secure enclave is necessary to prevent brute force attacks.

Eh maybe, what's the realistic threat model here? 99.9% of the time someone stealing a laptop isn't going to know or care what's on it, they'll just wipe it and sell the hardware. And in the rare case where you're seriously concerned about a competitor or spy making a targeted attack, you'll have a password policy where you're not using something bruteforceable.

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

#77

Post by lmm »

miki123211 wrote: post #65
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.

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.

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

How does secure boot help with that? Those kind of users aren't going to be pulling the CMOS battery to reset the BIOS password.

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

#78

Post by tom1337 »

mjg59 wrote: post #57
tom1337 wrote: post #49

Earlier quoted context omitted.

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.

I've found no evidence that it checks the set of trusted certs, only that secure boot is enabled (which is trivial to fake).

well then thats on me and i misunderstood. I thought that with secure boot enabled a tampered operating would not boot and therefore the anti cheat can expect that if secure boot is enabled the os is legit. but yea if secure boot enrollment can be faked then my point doesn't stand anymore.

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

#79

Post by FirmwareBurner »

autoexec wrote: post #69
FirmwareBurner wrote: post #41

Earlier quoted context omitted.

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

>Then why force it into consumer hardware?

It's not forced. You can disable secure boot and all that in BIOS.

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

#80

Post by Y_Y »

HPsquared wrote: post #72
Y_Y wrote: post #68

Earlier quoted context omitted.

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.

Some kind of secure enclave is necessary to prevent brute force attacks. Allows simple PIN unlock for users.

I'd argue that it's neither necessary nor sufficient for securing your data. (Convenience is another worthwhile consideration, of course.)

Cryptography should be enough to protect you from brute force, if you care about such things. I don't think it would be controversial to say that it's much more likely your particular secure enclave is broken than your encryption scheme (assuming you choose something appropriate and you're not on the NSA's radar).

Post reply on HN