3 ms·

I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something th

I was talking about the same "install" that is already done (pre-installed on the drive that is first booted). Enrolling certs into the UEFI isn't something that needs to be done manually when "Setup Mode" is enabled, the bootloader can automatically enroll them. This already is a thing with the exception of the ship in "Setup Mode" part. Though some motherboard UEFI implementations are shit (as to be expected) and shit their pants when this happens. See last paragraph in this section as example: https://www.freedesktop.org/software/systemd/man/latest/systemd-boot.html#Files https://www.freedesktop.org/software/systemd/man/latest/syst...

bri3d 8mo ago
What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?
- NekkoDroid 8mo ago
  It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
  - bri3d 8mo ago
    What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said. UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
    - fc417fc802 8mo ago
      > UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level Baseless FUD. If you have an actual point to make then do so. > All of these "add more nag screens for freedom" No one said anything about a nag screen. You literally just made that up. For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader.
      - bri3d 8mo ago
        > Baseless FUD. This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot? PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you. To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine. > No one said anything about a nag screen. The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today. > For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.
        okanat 8mo ago
        The breach in TFA happened because Microsoft actually did something benevolent and it blew up on their face. Now almost all of the hardware that takes security a bit seriously (basically expensive business class computers) have to upgrade their UEFI FW (many have already done ao via Windows Update). No single point of failure will protect you fully. UEFI SB is just one layer. And nobody ever would protect you from a dedicated nation state (except another nation state). Unless you own the entire supply chain from silicon contractors all the way up to every single software vendor and every single network operator, you cannot fully prove things aren't snitching on you.

bri3d 8mo ago

What would be the point of this change? It erodes security in some moderately meaningful way (even easier to supply chain new computers by swapping the boot disk) to add what amounts to either a nag screen or nothing, in exchange for some ideological purity about Microsoft certificates?

NekkoDroid 8mo ago
It really doesn't. UEFI are still not by default locked behind a password (can't be locked since you couldn't change settings in the UEFI if that were the case), so anyone that has access to change a drive can also disable secure boot or enroll their own keys if they want to do an actual supply chain attack. If your threat model is "has access to the system before first boot" you are fucked on anything that isn't locked down to only the manufacturer.
- bri3d 8mo ago
  What if my threat model is "compromised the disk imaging / disk supply chain?" This is a plausible and real threat model, and represents a moderate erosion, like I said. UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level anyway, so it's all just goofing around at this point from a security standpoint. All of these "add more nag screens for freedom" measures like the grandparent post and yours don't really seem useful to me, though.
  - fc417fc802 8mo ago
    > UEFI Secure Boot is also just not a meaningful countermeasure to anyone with even a moderate paranoia level Baseless FUD. If you have an actual point to make then do so. > All of these "add more nag screens for freedom" No one said anything about a nag screen. You literally just made that up. For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader.
    - bri3d 8mo ago
      > Baseless FUD. This is a fascinating thing to post on an article about… bypassing UEFI Secure Boot? PKFail, BlackLotus/BatonDrop, LogoFail, BootHole, the saga continues. If you’ve ever audited a UEFI firmware and decided it’s going to protect you, I’m not sure what to tell you. To be clear, it’s extremely useful and everyone should be using it. It’s also a train wreck. Both things can be true at the same time. Using Secure Boot + FDE keys sealed to PCRs keeps any rando from drive bying your machine. It also probably doesn’t stop a dedicated attacker from compromising your machine. > No one said anything about a nag screen. The parent post suggested that Secure Boot arrive in Setup Mode. Either the system can automatically enroll the first key it sees from disk (supply chain issue, like I posted) or nag screen a key hash / enrollment process. Or do what it does today. > For the record google pixels work largely this way. Flash image, test boot, re-lock bootloader So do UEFI systems. Install OS, test boot, enroll PK. What the OP is proposing is basically if your Android phone arrived and said “Hi! Would you like to trust software from Google?!?!” on first boot.
      - okanat 8mo ago
        The breach in TFA happened because Microsoft actually did something benevolent and it blew up on their face. Now almost all of the hardware that takes security a bit seriously (basically expensive business class computers) have to upgrade their UEFI FW (many have already done ao via Windows Update). No single point of failure will protect you fully. UEFI SB is just one layer. And nobody ever would protect you from a dedicated nation state (except another nation state). Unless you own the entire supply chain from silicon contractors all the way up to every single software vendor and every single network operator, you cannot fully prove things aren't snitching on you.