6 ms·

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 the

by 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.
  - mjg59 1y ago
    Which vendors?
    - tom1337 1y ago
      As example, FaceIT Anti Cheat only works if Secure Boot is enabled. I guess their argument is that they can ensure you only boot genuine Windows and thus they can better check if you've tampered with anything.
      - mjg59 1y ago
        I've found no evidence that it checks the set of trusted certs, only that secure boot is enabled (which is trivial to fake).
        tom1337 1y ago
        well then thats on me and i misunderstood. I thought that with secure boot enabled a tampered operating would not boot and therefore the anti cheat can expect that if secure boot is enabled the os is legit. but yea if secure boot enrollment can be faked then my point doesn't stand anymore.
      - Y_Y 1y ago
        https://www.theguardian.com/technology/blog/2006/jul/14/windowsgenuine https://www.theguardian.com/technology/blog/2006/jul/14/wind... I see Microsoft's malicious erosion of the meaning of "genuine" is going well.
    - c0l0 1y ago
      Microsoft, with Windows 11. No, the "LabConfig" bs does not count.
      - mjg59 1y ago
        Where does Windows 11 check the set of trusted certificates?
FirmwareBurner 1y ago
>I own a piece of hardware, so I can do what I want to it. It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other potential bad actors.
- autoexec 1y ago
  Then why force it into consumer hardware? If it were only available on enterprise servers nobody would care.
  - FirmwareBurner 1y ago
    >Then why force it into consumer hardware? It's not forced. You can disable secure boot and all that in BIOS.
    - autoexec 1y ago
      TPM has to be there. If you have a machine that doesn't support a high enough version your OS vendor will refuse to give you any support and if you have secure boot disabled the software you try to run might refuse to work. Today, you can disable secure boot and have a degraded experience, tomorrow, who knows? If this really were all only for enterprise users things like https://old.reddit.com/r/ValorantTechSupport/comments/1g4rkhp/van_restriction_secure_boot_verification_failure/ https://old.reddit.com/r/ValorantTechSupport/comments/1g4rkh... wouldn't be an issue but that isn't reality.
      - FirmwareBurner 1y ago
        Then buy a machine without TPM. Or buy games that don't require TPM. Of course online multiplayer games are gonna have more stringent device security requirements to try to deter cheaters on the PC platforms. Companies aren't gonna mass produce new HW and SW customized to your own individual desires just because you want something else than the masses of consumers don't care about. Vote with your wallet if TPM bothers you. Otherwise I don't see what your argument stands on.
lmm 1y ago
Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.
- HPsquared 1y ago
  With laptops, unauthorized physical access happens a lot more often. People lose them, they get stolen, etc.
  - Y_Y 1y ago
    Presumably drive encryption is necessary anyway to protect lost/stolen devices, and at that point modifying the bootloader won't be useful. I see the value when the attacker manages to modify the device without the user knowing, and causes them to unknowingly use an attacker-controlled OS, but that's a vastly different threat model.
    - HPsquared 1y ago
      Some kind of secure enclave is necessary to prevent brute force attacks. Allows simple PIN unlock for users.
      - lmm 1y ago
        > Some kind of secure enclave is necessary to prevent brute force attacks. Eh maybe, what's the realistic threat model here? 99.9% of the time someone stealing a laptop isn't going to know or care what's on it, they'll just wipe it and sell the hardware. And in the rare case where you're seriously concerned about a competitor or spy making a targeted attack, you'll have a password policy where you're not using something bruteforceable.
        patrakov 1y ago
        The supposed attack scenario is that the laptop is returned in a trojaned form with a kernel-based keylogger. The usual counterargument is that the laptop might be as well returned with a hardware-based keylogger.
mjg59 1y ago
You should be able to do what you want to it. You should also be able to configure it such that only you can do what you want to it, and nobody else can. Secure Boot protects against boot kits, malware that replaces the bootloader and backdoors the OS as it boots and before any other security protections kick in. Real world bootkits have been found in the wild, and we've even seen them use vulnerabilities in signed (now revoked) bootloaders, so we know secure boot has forced their developers to work harder. You may not be worried about that as a risk (well, until you are) but there are real people who this has genuinely protected. Is it worth it by default? Completely reasonable separate discussion to have. But is there a reason it exists? Absolutely.
AStonesThrow 1y ago
[dead]
heavyset_go 1y ago
Stick a BIOS password on your machine and turn on Secure Boot. Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc. You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered. Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run. This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.
- fsflover 1y ago
  > you are now secure against petty criminals stealing your data Ordinary disk encryption would protect me too here, wouldn't it?
  - npteljes 1y ago
    I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk. https://security.stackexchange.com/questions/267222/full-disk-encryption-legacy-boot-mode-mbr-vs-efi-boot-mode https://security.stackexchange.com/questions/267222/full-dis... So, there are two scenarios here. First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe. Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.
    - fsflover 1y ago
      The second case requires a professional, dedicated attacker. I use TPM with Heads and a hardware key to protect myself against it. It will notify me if the boot partition or BIOS are tampered with. As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.
RiverCrochet 1y ago
If an attacker gains root privileges on your system, an attacker can modify the bootloader on your boot device to load a different kernel than the one you have installed, possibly one that the attacker uploaded that may have backdoors, etc. Secure boot requires that the bootloader match a hash derived from a TPM-stored key. Of course, you get the same protection (and update hassle) by storing the bootloader in something that can't be written except when you specifically enable it. A better scheme than the UEFI secure boot/TPM junk is simply a 2GB SD card (enough to hold a bootloader, kernel, and initrd) in an SD card reader with a physical read/write switch. When it's time to update your bootloader or kernel, flip the switch to write mode, then flip it back - heck the system could even refuse to boot if write mode was enabled on boot. Honestly I don't know why the whole PC firmware shouldn't be on that SD card. Corrupt unbootable BIOSes can be fixed with a new SD card. For remote updates, the physical switch could be replaced with a GPIO pin and a Raspberry Pi that you connect to and log into separately. It's less secure than the physical switch but oodles more secure than what's there now - maybe not oodles but at least the software on a Pi is much higher quality than UEFI vendors.
- xinayder 1y ago
  If an attacker has root privileges to my Linux system, what's stopping them from overwriting my Linux kernel image in my boot partition with one that has backdoors?
  - mjg59 1y ago
    Secure boot.
    - xinayder 1y ago
      How is secure boot stopping them from overwriting my kernel image on the first place? Won't it just report that the kernel image was tampered and thus you cannot boot to the system? It does nothing to prevent overwriting the kernel image.
      - 1y ago
Nextgrid 1y ago
"BIOS vs UEFI" and Secure Boot are two different things. UEFI supports the latter if you want and configure it, but it's not a requirement of UEFI, and technically a BIOS could also implement signature verification of the boot sector.

by jrm4 1y ago

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.
- mjg59 1y ago
  Which vendors?
  - tom1337 1y ago
    As example, FaceIT Anti Cheat only works if Secure Boot is enabled. I guess their argument is that they can ensure you only boot genuine Windows and thus they can better check if you've tampered with anything.
    - mjg59 1y ago
      I've found no evidence that it checks the set of trusted certs, only that secure boot is enabled (which is trivial to fake).
      - tom1337 1y ago
        well then thats on me and i misunderstood. I thought that with secure boot enabled a tampered operating would not boot and therefore the anti cheat can expect that if secure boot is enabled the os is legit. but yea if secure boot enrollment can be faked then my point doesn't stand anymore.
    - Y_Y 1y ago
      https://www.theguardian.com/technology/blog/2006/jul/14/windowsgenuine https://www.theguardian.com/technology/blog/2006/jul/14/wind... I see Microsoft's malicious erosion of the meaning of "genuine" is going well.
  - c0l0 1y ago
    Microsoft, with Windows 11. No, the "LabConfig" bs does not count.
    - mjg59 1y ago
      Where does Windows 11 check the set of trusted certificates?

FirmwareBurner 1y ago

>I own a piece of hardware, so I can do what I want to it. It's not a feature for you, it's for enterprise/corporations. You might be the user of the PC, but your employer owns it, and they want it as locked down as possible both from you and from other potential bad actors.

autoexec 1y ago
Then why force it into consumer hardware? If it were only available on enterprise servers nobody would care.
- FirmwareBurner 1y ago
  >Then why force it into consumer hardware? It's not forced. You can disable secure boot and all that in BIOS.
  - autoexec 1y ago
    TPM has to be there. If you have a machine that doesn't support a high enough version your OS vendor will refuse to give you any support and if you have secure boot disabled the software you try to run might refuse to work. Today, you can disable secure boot and have a degraded experience, tomorrow, who knows? If this really were all only for enterprise users things like https://old.reddit.com/r/ValorantTechSupport/comments/1g4rkhp/van_restriction_secure_boot_verification_failure/ https://old.reddit.com/r/ValorantTechSupport/comments/1g4rkh... wouldn't be an issue but that isn't reality.
    - FirmwareBurner 1y ago
      Then buy a machine without TPM. Or buy games that don't require TPM. Of course online multiplayer games are gonna have more stringent device security requirements to try to deter cheaters on the PC platforms. Companies aren't gonna mass produce new HW and SW customized to your own individual desires just because you want something else than the masses of consumers don't care about. Vote with your wallet if TPM bothers you. Otherwise I don't see what your argument stands on.

lmm 1y ago

Theoretically you hook up your whole disk encryption to your secureboot and it protects you against "evil maid" attacks. But yeah I'm pretty sure in practice it's about making it harder to install Linux or watch imported Blurays.

HPsquared 1y ago
With laptops, unauthorized physical access happens a lot more often. People lose them, they get stolen, etc.
- Y_Y 1y ago
  Presumably drive encryption is necessary anyway to protect lost/stolen devices, and at that point modifying the bootloader won't be useful. I see the value when the attacker manages to modify the device without the user knowing, and causes them to unknowingly use an attacker-controlled OS, but that's a vastly different threat model.
  - HPsquared 1y ago
    Some kind of secure enclave is necessary to prevent brute force attacks. Allows simple PIN unlock for users.
    - lmm 1y ago
      > Some kind of secure enclave is necessary to prevent brute force attacks. Eh maybe, what's the realistic threat model here? 99.9% of the time someone stealing a laptop isn't going to know or care what's on it, they'll just wipe it and sell the hardware. And in the rare case where you're seriously concerned about a competitor or spy making a targeted attack, you'll have a password policy where you're not using something bruteforceable.
      - patrakov 1y ago
        The supposed attack scenario is that the laptop is returned in a trojaned form with a kernel-based keylogger. The usual counterargument is that the laptop might be as well returned with a hardware-based keylogger.

mjg59 1y ago

You should be able to do what you want to it. You should also be able to configure it such that only you can do what you want to it, and nobody else can. Secure Boot protects against boot kits, malware that replaces the bootloader and backdoors the OS as it boots and before any other security protections kick in. Real world bootkits have been found in the wild, and we've even seen them use vulnerabilities in signed (now revoked) bootloaders, so we know secure boot has forced their developers to work harder. You may not be worried about that as a risk (well, until you are) but there are real people who this has genuinely protected. Is it worth it by default? Completely reasonable separate discussion to have. But is there a reason it exists? Absolutely.

AStonesThrow 1y ago

[dead]

heavyset_go 1y ago

Stick a BIOS password on your machine and turn on Secure Boot. Unless there's an exploit in your firmware, you are now secure against petty criminals stealing your data to even somewhat sophisticated attacks from non-state actors via data exfiltration, software keyloggers, etc. You can go another step further and use Secure Boot in a chain of trust up to the kernel with Linux, ensuring everything up to the kernel from boot isn't tampered. Secure Boot isn't about protecting yourself from the OS or software, it's about establishing a chain of trust from the boot process up so you are running the system you intend to run. This comment assumes you're using disk encryption on top of Secure Boot. When doing FDE, unless your firmware supports it, part of the boot process must be unencrypted to spin up encrypted disk access, and to protect that process, you can sign the unencrypted software to ensure its authenticity despite lack of encryption.

fsflover 1y ago
> you are now secure against petty criminals stealing your data Ordinary disk encryption would protect me too here, wouldn't it?
- npteljes 1y ago
  I believe not. Even with full disk encryption, you need an unencrypted bootloader after uefi to decrypt the disk. https://security.stackexchange.com/questions/267222/full-disk-encryption-legacy-boot-mode-mbr-vs-efi-boot-mode https://security.stackexchange.com/questions/267222/full-dis... So, there are two scenarios here. First, PC with FDE + normal boot gets stolen. The attacker cannot get the data without the password, so it's safe. Second, unattended FDE + normal boot PC gets tampered with. Attacker manipulates the bootloader. Unsuspecting user later boots the tampered PC, unlocks the FDE, gets owned.
  - fsflover 1y ago
    The second case requires a professional, dedicated attacker. I use TPM with Heads and a hardware key to protect myself against it. It will notify me if the boot partition or BIOS are tampered with. As an advantage, all relevant code running on my computer is FLOSS and auditable, unlike the Secure Boot and UEFI.

RiverCrochet 1y ago

If an attacker gains root privileges on your system, an attacker can modify the bootloader on your boot device to load a different kernel than the one you have installed, possibly one that the attacker uploaded that may have backdoors, etc. Secure boot requires that the bootloader match a hash derived from a TPM-stored key. Of course, you get the same protection (and update hassle) by storing the bootloader in something that can't be written except when you specifically enable it. A better scheme than the UEFI secure boot/TPM junk is simply a 2GB SD card (enough to hold a bootloader, kernel, and initrd) in an SD card reader with a physical read/write switch. When it's time to update your bootloader or kernel, flip the switch to write mode, then flip it back - heck the system could even refuse to boot if write mode was enabled on boot. Honestly I don't know why the whole PC firmware shouldn't be on that SD card. Corrupt unbootable BIOSes can be fixed with a new SD card. For remote updates, the physical switch could be replaced with a GPIO pin and a Raspberry Pi that you connect to and log into separately. It's less secure than the physical switch but oodles more secure than what's there now - maybe not oodles but at least the software on a Pi is much higher quality than UEFI vendors.

xinayder 1y ago
If an attacker has root privileges to my Linux system, what's stopping them from overwriting my Linux kernel image in my boot partition with one that has backdoors?
- mjg59 1y ago
  Secure boot.
  - xinayder 1y ago
    How is secure boot stopping them from overwriting my kernel image on the first place? Won't it just report that the kernel image was tampered and thus you cannot boot to the system? It does nothing to prevent overwriting the kernel image.
    - 1y ago

Nextgrid 1y ago

"BIOS vs UEFI" and Secure Boot are two different things. UEFI supports the latter if you want and configure it, but it's not a requirement of UEFI, and technically a BIOS could also implement signature verification of the boot sector.