6 ms·

This article notes that "nobody actually enforces these expiry dates". So this is another way that secure boot is proven to be nowhere as secure as it claims to

This article notes that "nobody actually enforces these expiry dates". So this is another way that secure boot is proven to be nowhere as secure as it claims to be. Coupled with LogoFAIL and most hardware shipping with insecure debug keys.. has Secure Boot ever provided meaningful security? It sure causes all sorts of practical problems. https://arstechnica.com/security/2023/12/just-about-every-windows-and-linux-device-vulnerable-to-new-logofail-firmware-attack/ https://arstechnica.com/security/2023/12/just-about-every-wi... https://arstechnica.com/security/2024/07/secure-boot-is-completely-compromised-on-200-models-from-5-big-device-makers/ https://arstechnica.com/security/2024/07/secure-boot-is-comp...

OsrsNeedsf2P 1y ago
Was Secure Boot supposed to increase security? I thought Microsoft was using it to make it near impossible to install Linux
- mjg59 1y ago
  Linux distributions have been shipping with secure boot support since 2012, so if that was the goal it had already failed over a decade ago.
  - zahlman 1y ago
    The Linux Mint support forums keep telling people to try turning it off to fix problems, but I installed Mint just fine with it enabled on my 8 (at the time) year old hardware, before I'd even heard that there was such a thing. Anyway, it's good to hear that I probably don't have anything to worry about.
    - charcircuit 1y ago
      Unfortunately, hearing this is not surprising since desktop Linux users tolerate having poor security and rely on never ever running malware to keep themselves safe over having the operating system itself protect against malware.
      - zahlman 1y ago
        > Unfortunately, hearing this is not surprising since [users of an OS with a built-in file permissions system] tolerate having poor security and rely on [thinking about whom to trust and primarily sourcing their software from the distro package manager] to keep themselves safe over having the operating system itself [apply heuristics to try to decide whether things the user downloaded from random web sites are malware, while completely failing to provide transparency on whether double-clicking something will supply it as data to an existing program or treat it as itself a program]. I'm not understanding how it's the desktop Linux users who have to deal with poor security.
        sugarpimpdorsey 1y ago
        > users of an OS with a built-in file permissions system Lot of good that will do you when Linux users will curl | bash most any garbage. The Windows NT file permission system is far more advanced (and I'm not even including AppLocker or software whitelisting). > thinking about whom to trust and primarily sourcing their software from the distro package manager So "app store" is the wave of the future? The days of Linux users using magic healing crystals to protect themselves from malware are long over. Most malware these days targets Linux servers. If you think chmod u+x is what is preventing your computer from catching digital AIDS I have news for you.
        bayindirh 1y ago
        > Lot of good that will do you when Linux users will curl | bash most any garbage. Same for Windows users who zoom through UAC prompts without reading. > The Windows NT file permission system is far more advanced (and I'm not even including AppLocker or software whitelisting). ...and much more convoluted and easy to break while most systems allow unfettered access to everywhere. On the other hand SELinux and AppArmor already provide transparent system isolation for decades now, and they are completely invisible. If you want even more security, you can install an immutable distro. > So "app store" is the wave of the future? App stores are capitalist versions of software repositories which are present for more than 20 years now? Plus, these repositories are generally well-vetted and observed by their maintainers. > Most malware these days targets Linux servers. If you think chmod u+x is what is preventing your computer from catching digital AIDS I have news for you. No, instead many sysadmins who know what they're doing are depending on a layered security system, provided by Linux kernel and its peripheries. Containers, CGroups, namespaces, SELinux/AppArmor, package integrity checks, multiple limited users (with reduced capabilities as well), UNIX file permissions, and many more. If you think Linux only has file permissions for system security, I have news for you.
- michaelt 1y ago
  It increases security in certain circumstances. Mostly for Windows users at big corporations. For example, you want your users' laptop hard drives to be encrypted - but also you have users who regularly forget their passwords? With bitlocker their hard drive can decrypt itself, so they only need to remember their windows login, which you can reset remotely. You give laptops to your field workers, who have full physical access and would love to play video games or access netflix when work puts them in a hotel over night with nothing to do? With secure boot you can keep your precious spreadsheets locked down, even if they're willing to boot from USB sticks or swap the hard drive. And perhaps most importantly, it has "secure" in the name. So the corporation's IT security auditors will like to see it turned on even if they have only a vague understanding of what it does.
- okanat 1y ago
  Maybe you are too young for this but viruses modifying boot partitions was a big thing back then. It is simply impossible to inject some code without finding an exploit in UEFI with Secure Boot or somehow exploiting the kernel. It is still possible to do this kind of hack but it is 2 orders of magnitude harder.
  - ahartmetz 1y ago
    No, boot sector viruses were not a big thing, especially after DOS times. They existed, but they weren't the worst problem at any time.
- fuzzfactor 1y ago
  SecureBoot and UEFI were "bundled" with Windows 8.0 PC's to curtail the possibility of users easily installing Windows 7 instead. Earlier versions of Windows were a much bigger threat to adoption of Windows 8 than Linux was.
- Yeul 1y ago
  Is secure boot even enabled by default? I have never used it on my gaming PC and Windows doesn't seem to care.
  - jon-wood 1y ago
    Its a requirement on any device sold with Windows 11.
- jon-wood 1y ago
  Yes, it does, for some values of security. Operated correctly it allows you to know you can trust everything on your system from the UEFI firmware down, because if any part of that chain didn't match what you were expecting to be there the next step in the chain would refuse to execute. Most people experience this via Windows, which automatically sets up that chain of trust so that you can know you've not had a rootkit injected somewhere. In other cases it may be Linux or something more exotic booting, and it requires some management by whoever is operating the device, but that comes with the benefit of knowing that if one of our devices has got to the point of decrypting it's storage we can be reasonably confident that it hasn't been tampered with, and so we can trust it to send good data.
strstr 1y ago
With the default key hierarchies, the benefit is more limited. It raises the bar. Implementing known vulnerabilities takes work. And not ever configuration is vulnerable to every issue. And, for a lot of the vulns, the OS vendor shoves things in the dbx to mitigate. With custom hierarchies, it's a bit more compelling. But it's a lot of work to maintain.
mjg59 1y ago
The rollover coincides with stronger security policies for signed objects (enforcing code being read-only, that kind of thing) and people with stronger security requirements can remove trust in the old certificate to enforce that. Code has bugs. There's any number of critical vulnerabilities in Linux, Windows, MacOS that have allowed bypass of all security features - does that mean all security features remain security theatre?
- ploxiln 1y ago
  Most security features are, yeah. The cost in terms of freedom/flexibility and reliability/longevity is very high. But we're told, this is necessary, it's the only way to guarantee the security of the poor user. But if in practice the security wasn't actually guaranteed, for most motherboards over most years, due to pretty big dumb oversights ... was it worth the extreme costs? The cost of losing compatibility with older or newer software/hardware, of losing convenient repairs and recovery? Nope. You sold your soul for "guaranteed security" of securing the entire boot and runtime from the lowest level hardware up ... and didn't really get it anyway.
  - sabas123 1y ago
    You make it sound like security is a binary thing, which is not true.
armada651 1y ago
They clearly didn't want to leave a system unbootable because a certificate expired. In which case you would have no opportunity to update the certificate because you can't boot the system anymore. They could've used a time stamping service to include a signed timestamp in the binary to compare the expiry date against, but that still leaves the system unbootable after the time stamping certificate expires in the far future. Besides, a hacking group powerful enough to steal Microsoft's Secure Boot private key will likely be able to steal a timestamping private key from a certificate authority as well.
WhyNotHugo 1y ago
SecureBoot uses an existing certificate implementation which supported expiration, for a scenario where a having a reliable clock in unfeasible. SecureBoot would have been better off with certificates that never expire. That's not a problem in cases where users (or organisations) manage their own hosts, since they can just changed the certificate when the previous one is no longer valid or leaked or whatever. In practice, SecureBoot rolled out with a single CA for everyone, one controlled by Microsoft. This provides little value for anyone—restricting your computer to "only boot stuff signed by a third party" doesn't really protect from attackers in any way. They'll just boot into one of the many programs signed by MS. But because a single CA is used globally, you want expiration so as to roll them over every few years. But remember: there's no way to have a reliable clock. And so, we have the mess that we have. The grand majority of Linux users could disable SecureBoot tomorrow and their system's security would not change in any meaningful way.

OsrsNeedsf2P 1y ago

Was Secure Boot supposed to increase security? I thought Microsoft was using it to make it near impossible to install Linux

mjg59 1y ago
Linux distributions have been shipping with secure boot support since 2012, so if that was the goal it had already failed over a decade ago.
- zahlman 1y ago
  The Linux Mint support forums keep telling people to try turning it off to fix problems, but I installed Mint just fine with it enabled on my 8 (at the time) year old hardware, before I'd even heard that there was such a thing. Anyway, it's good to hear that I probably don't have anything to worry about.
  - charcircuit 1y ago
    Unfortunately, hearing this is not surprising since desktop Linux users tolerate having poor security and rely on never ever running malware to keep themselves safe over having the operating system itself protect against malware.
    - zahlman 1y ago
      > Unfortunately, hearing this is not surprising since [users of an OS with a built-in file permissions system] tolerate having poor security and rely on [thinking about whom to trust and primarily sourcing their software from the distro package manager] to keep themselves safe over having the operating system itself [apply heuristics to try to decide whether things the user downloaded from random web sites are malware, while completely failing to provide transparency on whether double-clicking something will supply it as data to an existing program or treat it as itself a program]. I'm not understanding how it's the desktop Linux users who have to deal with poor security.
      - sugarpimpdorsey 1y ago
        > users of an OS with a built-in file permissions system Lot of good that will do you when Linux users will curl | bash most any garbage. The Windows NT file permission system is far more advanced (and I'm not even including AppLocker or software whitelisting). > thinking about whom to trust and primarily sourcing their software from the distro package manager So "app store" is the wave of the future? The days of Linux users using magic healing crystals to protect themselves from malware are long over. Most malware these days targets Linux servers. If you think chmod u+x is what is preventing your computer from catching digital AIDS I have news for you.
        bayindirh 1y ago
        > Lot of good that will do you when Linux users will curl | bash most any garbage. Same for Windows users who zoom through UAC prompts without reading. > The Windows NT file permission system is far more advanced (and I'm not even including AppLocker or software whitelisting). ...and much more convoluted and easy to break while most systems allow unfettered access to everywhere. On the other hand SELinux and AppArmor already provide transparent system isolation for decades now, and they are completely invisible. If you want even more security, you can install an immutable distro. > So "app store" is the wave of the future? App stores are capitalist versions of software repositories which are present for more than 20 years now? Plus, these repositories are generally well-vetted and observed by their maintainers. > Most malware these days targets Linux servers. If you think chmod u+x is what is preventing your computer from catching digital AIDS I have news for you. No, instead many sysadmins who know what they're doing are depending on a layered security system, provided by Linux kernel and its peripheries. Containers, CGroups, namespaces, SELinux/AppArmor, package integrity checks, multiple limited users (with reduced capabilities as well), UNIX file permissions, and many more. If you think Linux only has file permissions for system security, I have news for you.
michaelt 1y ago
It increases security in certain circumstances. Mostly for Windows users at big corporations. For example, you want your users' laptop hard drives to be encrypted - but also you have users who regularly forget their passwords? With bitlocker their hard drive can decrypt itself, so they only need to remember their windows login, which you can reset remotely. You give laptops to your field workers, who have full physical access and would love to play video games or access netflix when work puts them in a hotel over night with nothing to do? With secure boot you can keep your precious spreadsheets locked down, even if they're willing to boot from USB sticks or swap the hard drive. And perhaps most importantly, it has "secure" in the name. So the corporation's IT security auditors will like to see it turned on even if they have only a vague understanding of what it does.
okanat 1y ago
Maybe you are too young for this but viruses modifying boot partitions was a big thing back then. It is simply impossible to inject some code without finding an exploit in UEFI with Secure Boot or somehow exploiting the kernel. It is still possible to do this kind of hack but it is 2 orders of magnitude harder.
- ahartmetz 1y ago
  No, boot sector viruses were not a big thing, especially after DOS times. They existed, but they weren't the worst problem at any time.
fuzzfactor 1y ago
SecureBoot and UEFI were "bundled" with Windows 8.0 PC's to curtail the possibility of users easily installing Windows 7 instead. Earlier versions of Windows were a much bigger threat to adoption of Windows 8 than Linux was.
Yeul 1y ago
Is secure boot even enabled by default? I have never used it on my gaming PC and Windows doesn't seem to care.
- jon-wood 1y ago
  Its a requirement on any device sold with Windows 11.
jon-wood 1y ago
Yes, it does, for some values of security. Operated correctly it allows you to know you can trust everything on your system from the UEFI firmware down, because if any part of that chain didn't match what you were expecting to be there the next step in the chain would refuse to execute. Most people experience this via Windows, which automatically sets up that chain of trust so that you can know you've not had a rootkit injected somewhere. In other cases it may be Linux or something more exotic booting, and it requires some management by whoever is operating the device, but that comes with the benefit of knowing that if one of our devices has got to the point of decrypting it's storage we can be reasonably confident that it hasn't been tampered with, and so we can trust it to send good data.

strstr 1y ago

With the default key hierarchies, the benefit is more limited. It raises the bar. Implementing known vulnerabilities takes work. And not ever configuration is vulnerable to every issue. And, for a lot of the vulns, the OS vendor shoves things in the dbx to mitigate. With custom hierarchies, it's a bit more compelling. But it's a lot of work to maintain.

mjg59 1y ago

The rollover coincides with stronger security policies for signed objects (enforcing code being read-only, that kind of thing) and people with stronger security requirements can remove trust in the old certificate to enforce that. Code has bugs. There's any number of critical vulnerabilities in Linux, Windows, MacOS that have allowed bypass of all security features - does that mean all security features remain security theatre?

ploxiln 1y ago
Most security features are, yeah. The cost in terms of freedom/flexibility and reliability/longevity is very high. But we're told, this is necessary, it's the only way to guarantee the security of the poor user. But if in practice the security wasn't actually guaranteed, for most motherboards over most years, due to pretty big dumb oversights ... was it worth the extreme costs? The cost of losing compatibility with older or newer software/hardware, of losing convenient repairs and recovery? Nope. You sold your soul for "guaranteed security" of securing the entire boot and runtime from the lowest level hardware up ... and didn't really get it anyway.
- sabas123 1y ago
  You make it sound like security is a binary thing, which is not true.

armada651 1y ago

They clearly didn't want to leave a system unbootable because a certificate expired. In which case you would have no opportunity to update the certificate because you can't boot the system anymore. They could've used a time stamping service to include a signed timestamp in the binary to compare the expiry date against, but that still leaves the system unbootable after the time stamping certificate expires in the far future. Besides, a hacking group powerful enough to steal Microsoft's Secure Boot private key will likely be able to steal a timestamping private key from a certificate authority as well.

WhyNotHugo 1y ago

SecureBoot uses an existing certificate implementation which supported expiration, for a scenario where a having a reliable clock in unfeasible. SecureBoot would have been better off with certificates that never expire. That's not a problem in cases where users (or organisations) manage their own hosts, since they can just changed the certificate when the previous one is no longer valid or leaked or whatever. In practice, SecureBoot rolled out with a single CA for everyone, one controlled by Microsoft. This provides little value for anyone—restricting your computer to "only boot stuff signed by a third party" doesn't really protect from attackers in any way. They'll just boot into one of the many programs signed by MS. But because a single CA is used globally, you want expiration so as to roll them over every few years. But remember: there's no way to have a reliable clock. And so, we have the mess that we have. The grand majority of Linux users could disable SecureBoot tomorrow and their system's security would not change in any meaningful way.