5 ms·

I'm having a hard time determining the actual risk here. It seems all of these issues are related to to the various ways of circumventing the Secure Boot proces

I'm having a hard time determining the actual risk here. It seems all of these issues are related to to the various ways of circumventing the Secure Boot process, but are people really relying on Secure Boot for security? Whenever I've looked at it, it seems like like it doesn't really solve any really security problems? What's the threat model where Secure Boot is useful? Widows might be doing something interesting with it, but does it help in the case of dual boot? I'm using Qubes OS myself so I don't think Secure Boot would ever be useful in my case?

JoachimSchipper 6y ago
Secure Boot can prevent an attacker who has compromised a system from persistently compromising said system - provided all data used by the system is properly authenticated. For a typical laptop, Secure Boot plus Full-Disk Encryption (e.g. Windows BitLocker) makes it harder but not impossible for an "evil maid" - an attacker with temporary, undetected access to the hardware - to compromise the system. (Note that Qubes' VM isolation, per se, does not help in an "evil maid" scenario! - the evil maid typically never even turns the system on.) There's a lot to say about Secure Boot, and Intel's "measured boot" is rather different from the usual authenticate-then-start approach. If you want to know more, Rutkowska's (of Qubes OS fame) "x86 considered harmful" has quite a lot of good information. [EDITed to properly spell Rutkowska’s name; thanks, e Erik!]
- enedil 6y ago
  Just a nitpick here, it is "Rutkowska" and not "Rutkovska" (although that is how you would pronounce the surname).
- dooglius 6y ago
  > the evil maid typically never even turns the system on What exactly are you imagining the maid doing, taking apart the laptop, removing the hard disk, mounting the EFI partition on another device... at that point, why not just install a physical keylogger? To me, this sort of threat model never made sense, once physical access is possible your main worry ought to be https://xkcd.com/538/ https://xkcd.com/538/
  - taldo 6y ago
    What about a rogue datacenter technician that plugs usb devices into a few servers? Or a wiring contractor that installs a pcie card on your servers while they're conveniently powered off during the weekend while they upgrade something? Sure, the $5 wrench attack makes sense to steal data from an individual's laptop, but keeping undetected persistent access to some servers/networks is, in many cases, much more valuable than a one-time data dump.
  - Foxboron 6y ago
    A physical keylogger is more complicated then messing with the EFI boot partition and adding some persistent code to the initramfs or kernel. Some people might say they have a detached bootloader (secondary USB which contains the LUKS headers+bootloader), but that depends on them actually keeping the two separate. Even then there is no way to authenticate what you are booting.
    - 1996 6y ago
      > Even then there is no way to authenticate what you are booting. Let me introduce you to TPM, signed binaries and measured boot! However, the most secure ways usually involve a flashed kernel (coreboot) on a write protected NAND chip, of course with encrypted root, that start the boot process by dumping and sha'ing the NAND and comparing that to the whitelist.
      - Foxboron 6y ago
        TPM usage assumes Secure Boot though. It's fairly useless if you are booting malicious files.
        1996 6y ago
        With enrolled keys and a password protected bios that refuses to add boot options to the boot menu, and refuse to boot existing options if the signature no longer matches, you can't be booting malicious files.
- bbarnett 6y ago
  Excuse me kind sir, where may one procure the services of an evil maid? Asking for a friend.
- madjam002 6y ago
  Is it possible to use secure boot to boot e.g a Linux environment with something like AppArmor enabled in a way that can’t be disabled without resigning a new bootloader?
  - lathiat 6y ago
    That’s generally the idea of “lockdown” mode but I’m not sure if it specifically applies to Apparmor. https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html
  - gruez 6y ago
    Secureboot alone can't do it, you'll need a TPM so the disk stays encrypted (and therefore protected from unwanted modifications) and to ensure the keys only get released if the bootloader is verified (to prevent the bootloader/kernel, which must remain unencrypted from being modified).
dogma1138 6y ago
Well SB on Linux allows you to sign things with a Machine Owner Key. The threat model here is a physical attack that either boots an unauthorized operating system or modified the binaries, how useful it is in the real world for most people I don’t know but it can provide some mitigation or at least a detection if someone is trying to mess with your boot sequence hastily like at the airport or overnight at the office. Basically you can say that if you lose control over the machine it’s not secure anymore which is somewhat true but in reality you can lock down the UEFI effectively enough that without any known vulnerabilities or bypasses even TLA will probably need quite some time to break into it especially without raising any alarms. The other threat model is that as long as the MoK signing key is not on the machine, any malware that compromises it won’t be able to add persistence in the bootloader layer.
Foxboron 6y ago
Qubes OS is actively working on Secure Boot though. There is also a discussion about pros/cons. https://github.com/QubesOS/qubes-issues/issues/4371 https://github.com/QubesOS/qubes-issues/issues/4371
fuzzfactor 6y ago
The purpose of Microsoft SecureBoot was to initially provide a false sense of insecurity (FUD) about Linux, since it simply needed to be disabled to boot anything other than Windows 8+, on machines built from that point forward. The threat was that users would continue to be able to install other operating systems like Linux or Windows 7 or XP, or multiboot these on brand new PC's no differently than IBM had always intended. As a universal bootloader, GRUB had always been able to boot Windows just as well as a Windows bootloader, and still could at the time but only if Microsoft SecureBoot was disabled if relying on UEFI. Windows bootloaders could always also boot Linux under BIOS, but not GPT. Just in time because Linux was getting more functional than ever, which could lead to actual popularity if left unchecked. Without further effort on Microsoft's part this has naturally morphed as intended into the significant open-source team effort needed to finally overcome the obstacle just to get back to boot parity on brand-new PC's having default firmware settings. Along the way looks like multiple revocations will be needed for things other than Windows, but eventually once everything is back on parity again these open-source leaders can dust off their hands and take pride in a job very well done. Looks like not less than about seven years getting there, this is by design. Still could be a moving target for a while, but Revocations-R-Us now. Remember how they said that GPT partitioning had no unaccounted-for sectors like MBR setups always traditionally had between sector 0 and the first sector of the first partition? (these were also one of the optional locations for GRUB to be installed) Well, they were lying and up until recently using GPT when Microsoft quietly moved their mysterious _Microsoft Reserved_ MSR partition to now be the very first possible one starting at sector 34, there had always been gobs of space, as much but usually much more than under BIOS. _Traditionaly_, the almost-nonexistent MSR had appeared (geometrically aligned) whether you wanted it or not in between the first usually hidden (boot or EFI) partition, and the first system volume (default C:) on the HDD. Now MSR exists too close to the beginning of the SSD or HDD to geometrically align with erase blocks or 4K sectors. When the concept of all-sectors-allocated is actually achieved, people have still always needed some out-of-partition sectors anyway, whether for GRUB or things like the old _drive overlays_ of BIOS use. So the MSR is there for that reason, but for Microsoft only not for you. But as always with GPT, sectors 2 through 33 by default still define all your partitions, 4 partitons to a sector. Unless you have more than 8 partitions, sectors 4 through 33 are still blank for everybody no differently than under BIOS. So much SecureBoot.
zlynx 6y ago
You need Secure Boot or something like it to start the security chain when using a TPM to save keys to unlock the hard drive, for example. The TPM can be used to verify that the next boot stage has not been compromised, but it cannot do the first step, so if bad code inserts itself right up front it can lie to the TPM and unlock the security keys under malware control.

JoachimSchipper 6y ago

Secure Boot can prevent an attacker who has compromised a system from persistently compromising said system - provided all data used by the system is properly authenticated. For a typical laptop, Secure Boot plus Full-Disk Encryption (e.g. Windows BitLocker) makes it harder but not impossible for an "evil maid" - an attacker with temporary, undetected access to the hardware - to compromise the system. (Note that Qubes' VM isolation, per se, does not help in an "evil maid" scenario! - the evil maid typically never even turns the system on.) There's a lot to say about Secure Boot, and Intel's "measured boot" is rather different from the usual authenticate-then-start approach. If you want to know more, Rutkowska's (of Qubes OS fame) "x86 considered harmful" has quite a lot of good information. [EDITed to properly spell Rutkowska’s name; thanks, e Erik!]

enedil 6y ago
Just a nitpick here, it is "Rutkowska" and not "Rutkovska" (although that is how you would pronounce the surname).
dooglius 6y ago
> the evil maid typically never even turns the system on What exactly are you imagining the maid doing, taking apart the laptop, removing the hard disk, mounting the EFI partition on another device... at that point, why not just install a physical keylogger? To me, this sort of threat model never made sense, once physical access is possible your main worry ought to be https://xkcd.com/538/ https://xkcd.com/538/
- taldo 6y ago
  What about a rogue datacenter technician that plugs usb devices into a few servers? Or a wiring contractor that installs a pcie card on your servers while they're conveniently powered off during the weekend while they upgrade something? Sure, the $5 wrench attack makes sense to steal data from an individual's laptop, but keeping undetected persistent access to some servers/networks is, in many cases, much more valuable than a one-time data dump.
- Foxboron 6y ago
  A physical keylogger is more complicated then messing with the EFI boot partition and adding some persistent code to the initramfs or kernel. Some people might say they have a detached bootloader (secondary USB which contains the LUKS headers+bootloader), but that depends on them actually keeping the two separate. Even then there is no way to authenticate what you are booting.
  - 1996 6y ago
    > Even then there is no way to authenticate what you are booting. Let me introduce you to TPM, signed binaries and measured boot! However, the most secure ways usually involve a flashed kernel (coreboot) on a write protected NAND chip, of course with encrypted root, that start the boot process by dumping and sha'ing the NAND and comparing that to the whitelist.
    - Foxboron 6y ago
      TPM usage assumes Secure Boot though. It's fairly useless if you are booting malicious files.
      - 1996 6y ago
        With enrolled keys and a password protected bios that refuses to add boot options to the boot menu, and refuse to boot existing options if the signature no longer matches, you can't be booting malicious files.
bbarnett 6y ago
Excuse me kind sir, where may one procure the services of an evil maid? Asking for a friend.
madjam002 6y ago
Is it possible to use secure boot to boot e.g a Linux environment with something like AppArmor enabled in a way that can’t be disabled without resigning a new bootloader?
- lathiat 6y ago
  That’s generally the idea of “lockdown” mode but I’m not sure if it specifically applies to Apparmor. https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html
- gruez 6y ago
  Secureboot alone can't do it, you'll need a TPM so the disk stays encrypted (and therefore protected from unwanted modifications) and to ensure the keys only get released if the bootloader is verified (to prevent the bootloader/kernel, which must remain unencrypted from being modified).

dogma1138 6y ago

Well SB on Linux allows you to sign things with a Machine Owner Key. The threat model here is a physical attack that either boots an unauthorized operating system or modified the binaries, how useful it is in the real world for most people I don’t know but it can provide some mitigation or at least a detection if someone is trying to mess with your boot sequence hastily like at the airport or overnight at the office. Basically you can say that if you lose control over the machine it’s not secure anymore which is somewhat true but in reality you can lock down the UEFI effectively enough that without any known vulnerabilities or bypasses even TLA will probably need quite some time to break into it especially without raising any alarms. The other threat model is that as long as the MoK signing key is not on the machine, any malware that compromises it won’t be able to add persistence in the bootloader layer.

Foxboron 6y ago

Qubes OS is actively working on Secure Boot though. There is also a discussion about pros/cons. https://github.com/QubesOS/qubes-issues/issues/4371 https://github.com/QubesOS/qubes-issues/issues/4371

fuzzfactor 6y ago

The purpose of Microsoft SecureBoot was to initially provide a false sense of insecurity (FUD) about Linux, since it simply needed to be disabled to boot anything other than Windows 8+, on machines built from that point forward. The threat was that users would continue to be able to install other operating systems like Linux or Windows 7 or XP, or multiboot these on brand new PC's no differently than IBM had always intended. As a universal bootloader, GRUB had always been able to boot Windows just as well as a Windows bootloader, and still could at the time but only if Microsoft SecureBoot was disabled if relying on UEFI. Windows bootloaders could always also boot Linux under BIOS, but not GPT. Just in time because Linux was getting more functional than ever, which could lead to actual popularity if left unchecked. Without further effort on Microsoft's part this has naturally morphed as intended into the significant open-source team effort needed to finally overcome the obstacle just to get back to boot parity on brand-new PC's having default firmware settings. Along the way looks like multiple revocations will be needed for things other than Windows, but eventually once everything is back on parity again these open-source leaders can dust off their hands and take pride in a job very well done. Looks like not less than about seven years getting there, this is by design. Still could be a moving target for a while, but Revocations-R-Us now. Remember how they said that GPT partitioning had no unaccounted-for sectors like MBR setups always traditionally had between sector 0 and the first sector of the first partition? (these were also one of the optional locations for GRUB to be installed) Well, they were lying and up until recently using GPT when Microsoft quietly moved their mysterious _Microsoft Reserved_ MSR partition to now be the very first possible one starting at sector 34, there had always been gobs of space, as much but usually much more than under BIOS. _Traditionaly_, the almost-nonexistent MSR had appeared (geometrically aligned) whether you wanted it or not in between the first usually hidden (boot or EFI) partition, and the first system volume (default C:) on the HDD. Now MSR exists too close to the beginning of the SSD or HDD to geometrically align with erase blocks or 4K sectors. When the concept of all-sectors-allocated is actually achieved, people have still always needed some out-of-partition sectors anyway, whether for GRUB or things like the old _drive overlays_ of BIOS use. So the MSR is there for that reason, but for Microsoft only not for you. But as always with GPT, sectors 2 through 33 by default still define all your partitions, 4 partitons to a sector. Unless you have more than 8 partitions, sectors 4 through 33 are still blank for everybody no differently than under BIOS. So much SecureBoot.

zlynx 6y ago

You need Secure Boot or something like it to start the security chain when using a TPM to save keys to unlock the hard drive, for example. The TPM can be used to verify that the next boot stage has not been compromised, but it cannot do the first step, so if bad code inserts itself right up front it can lie to the TPM and unlock the security keys under malware control.