←back to thread

Intel OEM Private Key Leak: A Blow to UEFI Secure Boot Security

(securityonline.info)
658 points transpute | 4 comments | 06 May 23 17:39 UTC | HN request time: 0.955s | source
Show context
mjg59 ◴[06 May 23 20:26 UTC] No.35845088[source]▶
The pervasiveness of secure boot has genuinely made things difficult for attackers - there'd have been no reason for the Black Lotus bootkit to jump through all the hoops it did if it weren't for secure boot, and the implementation of UEFI secure boot does make it possible to remediate in a way that wouldn't be the case without it.

But secure boot at the OS level (in the PC world, at least) is basically guaranteed to give users the ability to enable or disable it, change the policy to something that uses their own keys, and ensure that the system runs the software they want. When applied to firmware, that's not the case - if Boot Guard (or AMD's equivalent, Platform Secure Boot) is enabled, you don't get to replace your firmware with code you control. There's still a threat here (we've seen firmware-level attacks for pre-Boot Guard systems), but the question is whether the security benefit is worth the loss of freedom. I wrote about this a while back (https://mjg59.dreamwidth.org/58424.html) but I lean towards thinking that in most cases the defaults are bad, and if users want to lock themselves into only using vendor firmware that's something that users should be able to opt into.

replies(3): >>35847100 #>>35847323 #>>35849078 #
hathawsh ◴[07 May 23 01:46 UTC] No.35847100[source]▶
Would it be sensible to make that choice using a good old fashioned jumper? For example, when the jumper is connected to pins 1 and 2, the firmware must be signed by a list of vendor-controlled keys; when the jumper is connected to pins 2 and 3, the firmware must be signed by a list of user-managed keys. That way, I can choose what kind of freedom makes sense for me. Most people value the freedom of not having to worry about firmware, while others value the freedom to use or create their own firmware.
replies(3): >>35847580 #>>35847586 #>>35850841 #
mjg59 ◴[07 May 23 03:18 UTC] No.35847586[source]▶
No, because the entire point of this is to be resilient against physical attack - anyone re-flashing your firmware already has your case open and can just move the jumper while they're at it.
replies(3): >>35847702 #>>35847927 #>>35848639 #
1. Too ◴[07 May 23 04:26 UTC] No.35847927[source]▶
Taken to the extreme, someone with physical access could replace the whole unit, to something which has the malware pre installed.

A switch that can’t be controlled via software is at least more secure than the alternatives. If you check the jumper before booting up you can still be 100% sure even if someone previously flashed stuff onto it. Remember, it is called secure boot, not secure flash, so fw get verified again during boot up.

replies(1): >>35848307 #
2. LoganDark ◴[07 May 23 05:51 UTC] No.35848307[source]▶
> Taken to the extreme, someone with physical access could replace the whole unit, to something which has the malware pre installed.

Not really. Secure Boot also guards access to tamper-resistant security modules like the TPM. Replacing the whole machine would never give you access to the old TPM. And if, for example, the disk is encrypted using using keys stored in the TPM, replacing the board won't work. Same even for OS-level keychains and credential stores even if the entire disk isn't encrypted.

replies(1): >>35850537 #
3. hduebdivd ◴[07 May 23 12:07 UTC] No.35850537[source]▶
we both know this is false.

if i have access to the tpm and the system, i can MitM it.

safeboot is perfect in a theoritical ideal vacum. something that bored reaearchers look and nod.

but keys leaking, hardware hacks, etc... are not even considered to not disturb the safety blanket everyone wrapped themselves with. yeah it makes it inconvenient for boot kits, bit that's it. if you can install os updates, i can install a boot kit

replies(1): >>35908341 #
4. LoganDark ◴[11 May 23 21:01 UTC] No.35908341{3}[source]▶
> if i have access to the tpm and the system, i can MitM it.

This is if you unlock your machine after an attacker has had physical access to it. "Evil maid" attacks are well-known (that is what these are called, someone installing MitM hardware on your computer). Whether contemporary machines are actually resistant to it in practice I am not sure.