Most active commenters
  • mjg59(5)

←back to thread

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

(securityonline.info)
658 points transpute | 15 comments | 06 May 23 17:39 UTC | HN request time: 0.247s | source | bottom
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 #
1. 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 #
2. 14 ◴[07 May 23 03:39 UTC] No.35847702[source]▶
Ya sure but my threat level doesn’t include the worry of physical attacks like that.
replies(1): >>35847771 #
3. mjg59 ◴[07 May 23 03:53 UTC] No.35847771[source]▶
Then you don't need a jumper - you can trust the firmware to impose any policy you've set (re-flashing firmware is mediated by the firmware, so you can just have a setup option that lets you choose which signing keys are trusted)
replies(1): >>35848101 #
4. 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 #
5. nextaccountic ◴[07 May 23 05:04 UTC] No.35848101{3}[source]▶
Unless the firmware has a bug and code downloaded from the Internet can exploit it
replies(1): >>35848390 #
6. 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 #
7. simonh ◴[07 May 23 06:09 UTC] No.35848390{4}[source]▶
In which case you’re just hosed anyway. A jumper won’t change that.
8. zimmerfrei ◴[07 May 23 06:56 UTC] No.35848639[source]▶
However, all UEFI implementations (on PCs at least) allow anybody with physical access to disable Secure Boot, the classic method of just popping the button battery remaining valid to these days.

So, isn't this firmware protection with BootGuard only really meant to prevent rootkits from getting persistence?

PS: thanks for all the blog posts you share on the matter! they are really golden

replies(3): >>35848658 #>>35849069 #>>35849351 #
9. bpye ◴[07 May 23 06:59 UTC] No.35848658[source]▶
Kind of true? If you disable secure boot at least on Windows BitLocker will no longer unlock your disk at boot, and so you'll need to enter the recovery code at least once.
replies(1): >>35848831 #
10. zimmerfrei ◴[07 May 23 07:25 UTC] No.35848831{3}[source]▶
Yes, but that will happen also without BootGuard. So what does Bootguard add with respect to physical attacks?
replies(1): >>35849983 #
11. mjg59 ◴[07 May 23 08:12 UTC] No.35849069[source]▶
Secure Boot configuration is usually stored in flash, not battery-backed CMOS, so on most boards won't be wiped if you simply remove the battery. But if you do have physical access you can simply rewrite that variable in flash to disable it - doing so will change the TPM measurements and so Bitlocker (or whatever) will complain, so it's not silent.
12. TacticalCoder ◴[07 May 23 08:56 UTC] No.35849351[source]▶
> So, isn't this firmware protection with BootGuard only really meant to prevent rootkits from getting persistence?

I saw this "but it only prevent persistence" several times and I wonder...

Isn't preventing rootkit from getting persistence already a big win? Preventing a rootkit from getting persistence also means that should a new signed kernel contain a security fix fixing the hole the rootkit was exploiting be installed, the rootkit won't work at all anymore. The attacker now needs not only to root the machine at each boot, he also needs to cross fingers that a kernel patch closing the hole he's exploiting doesn't get installed (or he needs to both prevent the new kernel from being installed while, at the same time, managing to make believe it's been installed).

Which also raises the probability the exploit he's using at every boot gets detected at some point.

How is this a win for attackers?

Are black hat hackers really thinking "Great, BootGuard and SecureBoot are getting ubiquitous, everything up to the kernel loading is signed and enforced, so now things are easier for me!"?

13. mjg59 ◴[07 May 23 10:28 UTC] No.35849983{4}[source]▶
If the target doesn't have BootGuard, you replace the firmware with one that pretends that Secure Boot is enabled even if it isn't and Bitlocker is unaware anything's changed.
14. hduebdivd ◴[07 May 23 12:07 UTC] No.35850537{3}[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 #
15. LoganDark ◴[11 May 23 21:01 UTC] No.35908341{4}[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.