19 ms·

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

126 points by vitplister 1y ago

vitarnixofntrnt 1y ago
[dead]
db48x 1y ago
> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.
- candiddevmike 1y ago
  This is all too common with any kind of user infantilizing security feature. Trust us bro, it's secure.
  - ahepp 1y ago
    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 garbage vendor code which is all an attack surface.
    - AnthonyMouse 1y ago
      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 configured, and so on. That doesn't require any certificates and you get 100% of the benefits. The firmware needs to verify the boot loader and the boot loader the OS etc. The OS doesn't need to verify the firmware because it can't because if the firmware or boot loader was compromised then the code in the OS to validate it would be just as compromised. The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else. And then you also don't get this "garbage code is nonetheless trusted" problem because there is no global root of trust and you never told your firmware to trust this random firmware update utility for somebody else's hardware.
      - gruez 1y ago
        >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? >The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else. TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. It'd be clumsy, but doable, just like your idea of using hashes for verification.
        AnthonyMouse 1y ago
        > 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.
        mjg59 1y ago
        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.
        AnthonyMouse 1y ago
        > How does the system know whether the new bootloader is legitimate or not? However it wants to. Maybe the existing bootloader (chosen by the owner rather than the vendor) or the OS it loads has its own signature verification system for update packages, like apt-get. Maybe the OS downloads it from a trusted URL via HTTPS and relies on web PKI. Maybe it uses Kerberos authentication to get it from the organization's own update servers. Maybe it just boots an OS that allows the operator to apply any update they want from a USB stick, but only after authenticating with the OS. None of that is the firmware's problem, all it has to do is disallow modifications to itself unless the owner has entered the firmware password or the system is booted from the owner-designated trusted bootloader. > All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys. The point isn't which device has the keys, it's that it shouldn't contain any from the factory. Nothing good can come of it.
- OjotCewIo 1y ago
  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.
  - gmueckl 1y ago
    Security is competing with all other requirements that a product has. That's all there is to it.
  - EPWN3D 1y ago
    They're not. They're ravaged by probably the same quality or slightly higher than average. The cost of mistakes is just way higher.
  - db48x 1y ago
    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.
    - bradfa 1y ago
      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 a preexisting firmware from an IBV and you get all their security bugs included. You’re lucky if you get full source code and it actually compiles. This is the state of our industry today.
      - wmf 1y ago
- getcrunk 1y ago
  Yea but when things like this keep happening … it becomes a pattern. A very convenient one at that.
- eukara 1y ago
  or they have read the Simple Sabotage Field Manual.
deleted 1y ago
[deleted]
baxtr 1y ago
> Because the attacker’s code executes before the operating system even loads, it opens the door for attackers to install bootkits and undermine OS-level security defenses. Excellent.
fsflover 1y ago
Fortunately there's a FLOSS alternative: TPM with Heads, https://osresearch.net/ https://osresearch.net/. Works for me.
- 1oooqooq 1y ago
  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
  - dietr1ch 1y ago
    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.
    - hulitu 1y ago
      > I guess things are better now, A bit. But compared to BIOS is still crap. The main advantage of UEFI over BIOS is that it offers RCE. /s
      - worthless-trash 1y ago
        Do most UEFI allow for the "R" in RCE?
- getcrunk 1y ago
  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
  - fsflover 1y ago
    Indeed I'm using a Librem laptop with Pureboot. Librem 14v1 has been discontinued, Purism is developing the second version, hopefully with a newer CPU.
jerhewet 1y ago
Please ... just give me back my BIOS.
- gruez 1y ago
  BIOS isn't magically secure either. It has no secureboot so it just runs whatever.
  - Lammy 1y ago
    I refuse to endorse any mindset where my Personal Computer unquestionably running my code could be considered a bad thing.
    - gruez 1y ago
      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.
      - Lammy 1y ago
        > all the secureboot implementations I've seen allow you to either disable it or enroll your own keys Here you go — now you have. Thank ${DEITY} for exploits! https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot https://openrt.gitbook.io/open-surfacert/common/boot-sequence/uefi/secure-boot https://openrt.gitbook.io/open-surfacert/common/boot-sequenc...
  - hulitu 1y ago
    secureboot also runs "whatever". It is just picky about which "whatever" it runs (hint: it runs the "whatever" for which Microsoft has the keys).
  - lmm 1y ago
    In theory, sure. In practice I'd bet UEFI-based systems are easier to compromise, because the attack surface is just so much larger.
jrm4 1y ago
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.
- JCattheATM 1y ago
  > I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. Apart from way nicer boot menus and bootloader setup? In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression. > Out there, there is software, which I have to figure out how I'm going to trust, Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
- necovek 1y ago
  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.
  - josefx 1y ago
    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.
  - c0l0 1y ago
    It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on top of these vendors' platforms - refuse to work on your machine.
jeffrallen 1y ago
A fish, a gun, and a smoking barrel. Sigh.
pabs3 1y ago
I wish the hardware industry went more in the direction of the State Considered Harmful paper: https://blog.invisiblethings.org/papers/2015/state_harmful.pdf https://blog.invisiblethings.org/papers/2015/state_harmful.p... https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably-secure-laptop/ https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably...
- fsflover 1y ago
  https://forum.qubes-os.org/t/why-does-qubes-os-not-get-more-attention-from-big-players/27897/ https://forum.qubes-os.org/t/why-does-qubes-os-not-get-more-... https://forum.qubes-os.org/t/deployments-of-qubes-by-entities-with-serious-stakes/8019 https://forum.qubes-os.org/t/deployments-of-qubes-by-entitie...

126 points by vitplister 1y ago

[dead]

> The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Sheer incompetence, in other words.

candiddevmike 1y ago
This is all too common with any kind of user infantilizing security feature. Trust us bro, it's secure.
- ahepp 1y ago
  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 garbage vendor code which is all an attack surface.
  - AnthonyMouse 1y ago
    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 configured, and so on. That doesn't require any certificates and you get 100% of the benefits. The firmware needs to verify the boot loader and the boot loader the OS etc. The OS doesn't need to verify the firmware because it can't because if the firmware or boot loader was compromised then the code in the OS to validate it would be just as compromised. The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else. And then you also don't get this "garbage code is nonetheless trusted" problem because there is no global root of trust and you never told your firmware to trust this random firmware update utility for somebody else's hardware.
    - gruez 1y ago
      >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? >The only thing the signature gets you is remote attestation, which is the evil to be prevented. Simple hashing would get you everything else. TPMs can do remote attestation without signatures just fine, by measuring the hash of the bootloader. It'd be clumsy, but doable, just like your idea of using hashes for verification.
      - AnthonyMouse 1y ago
        > 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.
        mjg59 1y ago
        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.
        AnthonyMouse 1y ago
        > How does the system know whether the new bootloader is legitimate or not? However it wants to. Maybe the existing bootloader (chosen by the owner rather than the vendor) or the OS it loads has its own signature verification system for update packages, like apt-get. Maybe the OS downloads it from a trusted URL via HTTPS and relies on web PKI. Maybe it uses Kerberos authentication to get it from the organization's own update servers. Maybe it just boots an OS that allows the operator to apply any update they want from a USB stick, but only after authenticating with the OS. None of that is the firmware's problem, all it has to do is disallow modifications to itself unless the owner has entered the firmware password or the system is booted from the owner-designated trusted bootloader. > All TPMs have private keys from the factory. They're entirely unrelated to the secure boot keys. The point isn't which device has the keys, it's that it shouldn't contain any from the factory. Nothing good can come of it.
OjotCewIo 1y ago
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.
- gmueckl 1y ago
  Security is competing with all other requirements that a product has. That's all there is to it.
- EPWN3D 1y ago
  They're not. They're ravaged by probably the same quality or slightly higher than average. The cost of mistakes is just way higher.
- db48x 1y ago
  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.
  - bradfa 1y ago
    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 a preexisting firmware from an IBV and you get all their security bugs included. You’re lucky if you get full source code and it actually compiles. This is the state of our industry today.
    - wmf 1y ago
getcrunk 1y ago
Yea but when things like this keep happening … it becomes a pattern. A very convenient one at that.
eukara 1y ago
or they have read the Simple Sabotage Field Manual.

deleted 1y ago

[deleted]

baxtr 1y ago

> Because the attacker’s code executes before the operating system even loads, it opens the door for attackers to install bootkits and undermine OS-level security defenses. Excellent.

fsflover 1y ago

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

1oooqooq 1y ago
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
- dietr1ch 1y ago
  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.
  - hulitu 1y ago
    > I guess things are better now, A bit. But compared to BIOS is still crap. The main advantage of UEFI over BIOS is that it offers RCE. /s
    - worthless-trash 1y ago
      Do most UEFI allow for the "R" in RCE?
getcrunk 1y ago
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
- fsflover 1y ago
  Indeed I'm using a Librem laptop with Pureboot. Librem 14v1 has been discontinued, Purism is developing the second version, hopefully with a newer CPU.

jerhewet 1y ago

Please ... just give me back my BIOS.

gruez 1y ago
BIOS isn't magically secure either. It has no secureboot so it just runs whatever.
- Lammy 1y ago
  I refuse to endorse any mindset where my Personal Computer unquestionably running my code could be considered a bad thing.
  - gruez 1y ago
    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.
    - Lammy 1y ago
      > all the secureboot implementations I've seen allow you to either disable it or enroll your own keys Here you go — now you have. Thank ${DEITY} for exploits! https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot https://wiki.ubuntu.com/ARM/SurfaceRT#Secure_Boot https://openrt.gitbook.io/open-surfacert/common/boot-sequence/uefi/secure-boot https://openrt.gitbook.io/open-surfacert/common/boot-sequenc...
- hulitu 1y ago
  secureboot also runs "whatever". It is just picky about which "whatever" it runs (hint: it runs the "whatever" for which Microsoft has the keys).
- lmm 1y ago
  In theory, sure. In practice I'd bet UEFI-based systems are easier to compromise, because the attack surface is just so much larger.

jrm4 1y ago

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.

JCattheATM 1y ago
> I still genuinely struggle to understand the advantage of UEFI/Secureboot whatever over BIOS. Apart from way nicer boot menus and bootloader setup? In a security context, it prevents a whole host of attacks, it's clearly an advantage and a much needed progression. > Out there, there is software, which I have to figure out how I'm going to trust, Yes, and with secureboot, if you guess wrong, that malicious software can do less damage than it otherwise could.
necovek 1y ago
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.
- josefx 1y ago
  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.
- c0l0 1y ago
  It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on top of these vendors' platforms - refuse to work on your machine.

jeffrallen 1y ago

A fish, a gun, and a smoking barrel. Sigh.

pabs3 1y ago

I wish the hardware industry went more in the direction of the State Considered Harmful paper: https://blog.invisiblethings.org/papers/2015/state_harmful.pdf https://blog.invisiblethings.org/papers/2015/state_harmful.p... https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably-secure-laptop/ https://www.qubes-os.org/news/2017/07/08/toward-a-reasonably...

fsflover 1y ago
https://forum.qubes-os.org/t/why-does-qubes-os-not-get-more-attention-from-big-players/27897/ https://forum.qubes-os.org/t/why-does-qubes-os-not-get-more-... https://forum.qubes-os.org/t/deployments-of-qubes-by-entities-with-serious-stakes/8019 https://forum.qubes-os.org/t/deployments-of-qubes-by-entitie...