5 ms·

> No "ordinary" user was ever compromised by accidentally installing Linux making his computing less safe. This is complete fantasy. That's incorrect. There is

> No "ordinary" user was ever compromised by accidentally installing Linux making his computing less safe. This is complete fantasy. That's incorrect. There is malware out there that can only work if you don't have Secure Boot enabled. The setting OP didn't disable, Device Guard, prevents the abuse of 3rd party signed bootloaders, another attack vector basically. This is a step up for most people that ever stay on Windows and doesn't affect the slightest someone who wants to install Linux, they still have to boot from an external device or wish to change a few UEFI settings. > Of course this is a mechanism to further advertise locking down general computing and nothing else. It is not new and security is a bad excuse. Framing Secure Boot as some kind of Secure Boogeyman is not conducive, brings the discussion into tinfoil scenarios without any potential practical outcome (nobody is going to remove SB or DG). As long as Linux vendors or people can get or enroll their own keys and disable any potential presets, it's a step up in security for everyone.

mjg59 4y ago
Could you please describe the attack vector that permitting third party boot loaders allows?
- Avamander 4y ago
  A signed rootkit created by abusing either an existing signed bootloader or shim. Of course it will change some TPM measurements, but those only matter after BitLocker has been enabled.
  - mjg59 4y ago
    If you care about security then you have bitlocker enabled.
    - Avamander 4y ago
      Yeah sure, but in this branch of the thread we're talking about the average user here.
      - mjg59 4y ago
        Then this doesn't matter, because you haven't set a password on your firmware and the attacker can just turn on the "Trust the Microsoft 3rd Party UEFI CA" option
        Avamander 4y ago
        That requires physical access, it won't work with a drive-by malware infection.
        mjg59 4y ago
        The average user has Bitlocker enabled and sealed to PCR 7, because that's been the default for years. A drive-by malware infection will be blocked by that. The ones who aren't in that scenario probably aren't using hardware that has this configuration, so it does nothing to protect them. If you're looking for the set of people who have hardware that defaults to this configuration, and who are targets of adversaries performing bootkit attacks, and who don't have a Bitlocker configuration that's sealed to PCR 7, I'd actually be willing to bet that you're going to find 0 of them.
        Avamander 4y ago
        > The average user has Bitlocker enabled and sealed to PCR 7, because that's been the default for years. No, very few models sold auto-encrypt because most have *the very least* one untrusted DMA-capable bus. They might even have Device Guard enabled, but that's often insufficient. Not to mention other reasons why devices might be considered noncompliant, like lack of HSTI (though that's more common with desktop motherboards, of which some might even have all other features Device Guard consists of). At this point in time, I'd consider auto-encryption rare. Maybe in five years and a few refresh cycles. > A drive-by malware infection will be blocked by that. The ones who aren't in that scenario probably aren't using hardware that has this configuration, so it does nothing to protect them. No, because previous point. > who are targets of adversaries performing bootkit attacks, and who don't have a Bitlocker configuration that's sealed to PCR 7, I'd actually be willing to bet that you're going to find 0 of them. Me finding someone getting actually targeted? Indeed unlikely. Me finding someone with some especially nasty variant of Emotet? Not at all unlikely. Device Guard enabled devices certainly make life harder for attackers, even if BitLocker is not (auto-)enabled.
  - tlamponi 4y ago
    The same vector is applicable for Microsofts loader, so not really one that only the externals are susceptible and again no benefit in security. Microsoft doesn't signs arbitrary bootloaders, normally just the shim from RH that needs to have a list of earlier signed 2nd stage bootloader (versions) with now known security issues and reject them.
sjmulder 4y ago
This is not about the presence of Secure Boot, but about distrusting 3rd party CA's. For example, my Dell XPS, with default Secure Boot settings, will boot official Fedora builds. This will not.
- Avamander 4y ago
  Yes, I did say it's not Secure Boot, it's part of Device Guard that OP didn't disable. It will boot say Fedora, if that option is disabled. No biggie.
tlamponi 4y ago
Note, this is about not booting from signed and verified bootloaders, using the 3rd party Microsoft CA, which need to go through quite some hoops already to get verified, not some unverified and/or unsigned loader. Debian, Fedora, ... use already trusted and signed bootchains, but they are excluded by choice without any benefit of security whatsoever. IMO this smell again like classic Microsoft EEE...
- Sakos 4y ago
  Debian and Fedora work fine with Secure Boot though.
  - Avamander 4y ago
    They don't work with Device Guard, but as I mentioned a comment above the previous, it can be disabled.
AshamedCaptain 4y ago
> Framing Secure Boot as some kind of Secure Boogeyman is not conducive, brings the discussion into tinfoil scenarios without any potential practical outcome (nobody is going to remove SB or DG) So, we're literally at the point where we have to disable parts of chip (the Device Guard / Secure Core / Pluton) in order to boot _any_ non-MS OS scenario, and you are still claiming that this is scaremongering ? At which point it stops being a "tinfoil" discussion ? > As long as Linux vendors or people can get or enroll their own keys and disable any potential presets, it's a step up in security for everyone. Microsoft _already_ promised that there would be a way so that non-MS OS manufacturers would be able to sign their software so that it would NOT REQUIRE fiddling with the system firmware in order to boot them, even with Secure Boot enabled. This is what the UEFI CA was for. You just insert a SUSE USB pendrive, use the firmware boot manager (or even Windows own' "boot from USB device" option in the Settings panel!) and that's it. Your system is no more compromised by this CA than by allowing MS OSes in the first place. This CA is MS, too. They vet everything they sign. They blacklist stuff that could have been used to compromise devices. They have forced GRUB among many other distributions to align to their whims in order to be signed. Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware. You have to fiddle with the system firmware, battle with a lot of Scary Boot Prompts that will drive many users away (even advanced ones!), and with the easiest option likely being to disable Secure Boot altogether which per your own words will reduce the security level of users. Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings, no matter if the device came with no OS or even a Linux distro to begin with. I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ? Give me a break.
- Avamander 4y ago
  > So, we're literally at the point where we have to disable parts of chip (the Device Guard / Secure Core / Pluton) part in order to boot _any_ non-OS scenario, and you are still claiming that this is scaremongering ? Yes, because the same way you have to enable booting from an USB stick. > At which point it stops being a "tinfoil" discussion ? See my last sentence in my previous comment. > Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings, Making a fresh install of Windows is equal in complexity, but it is preinstalled more often certainly. > Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware. That's not a case with Secure Boot alone, it's a case with Device Guard. Device Guard you can disable. It's a toggle like all the rest, no promises broken. > I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ? Yes, because what you've said is not correct.
otabdeveloper4 4y ago
> Linux vendors Do you really run a Linux that comes from a "vendor"? Sucks to be you.
- phendrenad2 4y ago
  Probably just a fancy way to say "provider".

mjg59 4y ago

Could you please describe the attack vector that permitting third party boot loaders allows?

Avamander 4y ago
A signed rootkit created by abusing either an existing signed bootloader or shim. Of course it will change some TPM measurements, but those only matter after BitLocker has been enabled.
- mjg59 4y ago
  If you care about security then you have bitlocker enabled.
  - Avamander 4y ago
    Yeah sure, but in this branch of the thread we're talking about the average user here.
    - mjg59 4y ago
      Then this doesn't matter, because you haven't set a password on your firmware and the attacker can just turn on the "Trust the Microsoft 3rd Party UEFI CA" option
      - Avamander 4y ago
        That requires physical access, it won't work with a drive-by malware infection.
        mjg59 4y ago
        The average user has Bitlocker enabled and sealed to PCR 7, because that's been the default for years. A drive-by malware infection will be blocked by that. The ones who aren't in that scenario probably aren't using hardware that has this configuration, so it does nothing to protect them. If you're looking for the set of people who have hardware that defaults to this configuration, and who are targets of adversaries performing bootkit attacks, and who don't have a Bitlocker configuration that's sealed to PCR 7, I'd actually be willing to bet that you're going to find 0 of them.
        Avamander 4y ago
        > The average user has Bitlocker enabled and sealed to PCR 7, because that's been the default for years. No, very few models sold auto-encrypt because most have *the very least* one untrusted DMA-capable bus. They might even have Device Guard enabled, but that's often insufficient. Not to mention other reasons why devices might be considered noncompliant, like lack of HSTI (though that's more common with desktop motherboards, of which some might even have all other features Device Guard consists of). At this point in time, I'd consider auto-encryption rare. Maybe in five years and a few refresh cycles. > A drive-by malware infection will be blocked by that. The ones who aren't in that scenario probably aren't using hardware that has this configuration, so it does nothing to protect them. No, because previous point. > who are targets of adversaries performing bootkit attacks, and who don't have a Bitlocker configuration that's sealed to PCR 7, I'd actually be willing to bet that you're going to find 0 of them. Me finding someone getting actually targeted? Indeed unlikely. Me finding someone with some especially nasty variant of Emotet? Not at all unlikely. Device Guard enabled devices certainly make life harder for attackers, even if BitLocker is not (auto-)enabled.
- tlamponi 4y ago
  The same vector is applicable for Microsofts loader, so not really one that only the externals are susceptible and again no benefit in security. Microsoft doesn't signs arbitrary bootloaders, normally just the shim from RH that needs to have a list of earlier signed 2nd stage bootloader (versions) with now known security issues and reject them.

sjmulder 4y ago

This is not about the presence of Secure Boot, but about distrusting 3rd party CA's. For example, my Dell XPS, with default Secure Boot settings, will boot official Fedora builds. This will not.

Avamander 4y ago
Yes, I did say it's not Secure Boot, it's part of Device Guard that OP didn't disable. It will boot say Fedora, if that option is disabled. No biggie.

tlamponi 4y ago

Note, this is about not booting from signed and verified bootloaders, using the 3rd party Microsoft CA, which need to go through quite some hoops already to get verified, not some unverified and/or unsigned loader. Debian, Fedora, ... use already trusted and signed bootchains, but they are excluded by choice without any benefit of security whatsoever. IMO this smell again like classic Microsoft EEE...

Sakos 4y ago
Debian and Fedora work fine with Secure Boot though.
- Avamander 4y ago
  They don't work with Device Guard, but as I mentioned a comment above the previous, it can be disabled.

AshamedCaptain 4y ago

> Framing Secure Boot as some kind of Secure Boogeyman is not conducive, brings the discussion into tinfoil scenarios without any potential practical outcome (nobody is going to remove SB or DG) So, we're literally at the point where we have to disable parts of chip (the Device Guard / Secure Core / Pluton) in order to boot _any_ non-MS OS scenario, and you are still claiming that this is scaremongering ? At which point it stops being a "tinfoil" discussion ? > As long as Linux vendors or people can get or enroll their own keys and disable any potential presets, it's a step up in security for everyone. Microsoft _already_ promised that there would be a way so that non-MS OS manufacturers would be able to sign their software so that it would NOT REQUIRE fiddling with the system firmware in order to boot them, even with Secure Boot enabled. This is what the UEFI CA was for. You just insert a SUSE USB pendrive, use the firmware boot manager (or even Windows own' "boot from USB device" option in the Settings panel!) and that's it. Your system is no more compromised by this CA than by allowing MS OSes in the first place. This CA is MS, too. They vet everything they sign. They blacklist stuff that could have been used to compromise devices. They have forced GRUB among many other distributions to align to their whims in order to be signed. Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware. You have to fiddle with the system firmware, battle with a lot of Scary Boot Prompts that will drive many users away (even advanced ones!), and with the easiest option likely being to disable Secure Boot altogether which per your own words will reduce the security level of users. Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings, no matter if the device came with no OS or even a Linux distro to begin with. I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ? Give me a break.

Avamander 4y ago
> So, we're literally at the point where we have to disable parts of chip (the Device Guard / Secure Core / Pluton) part in order to boot _any_ non-OS scenario, and you are still claiming that this is scaremongering ? Yes, because the same way you have to enable booting from an USB stick. > At which point it stops being a "tinfoil" discussion ? See my last sentence in my previous comment. > Not to mention of the unfair advantage MS has since their OSes will still boot transparently on these hardware, no matter what the firmware settings, Making a fresh install of Windows is equal in complexity, but it is preinstalled more often certainly. > Removing this key and relenting on this promise (which actually they have already done several times) means that there is NO WAY for a non-MS operating system to transparently boot on Secure Boot hardware. That's not a case with Secure Boot alone, it's a case with Device Guard. Device Guard you can disable. It's a toggle like all the rest, no promises broken. > I have already claimed that MS revoking a distro's signatures is basically a death sentence for that distro. Here we have an article about a manufacturer revoking _all_ distro's signatures, and you claim that "this is not a conductive discussion" ? Yes, because what you've said is not correct.

otabdeveloper4 4y ago

> Linux vendors Do you really run a Linux that comes from a "vendor"? Sucks to be you.

phendrenad2 4y ago
Probably just a fancy way to say "provider".