3 ms·

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

by mjg59 4y ago

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.
        mjg59 4y ago
        Systems have been shipping for years without any untrusted DMA-capable buses (source: I audited a bunch of this in a large enterprise). Anyone who's currently shipping systems with the 3rd Party UEFI CA disabled by default who isn't disabling untrusted DMA-capable buses is selling snakeoil, and the ones who do aren't obtaining meaningful additional security by doing so.
        Avamander 4y ago
        > Systems have been shipping for years without any untrusted DMA-capable buses (source: I audited a bunch of this in a large enterprise) That's your mistake here, you saw it in a large enterprise, the context is "average user". > 3rd Party UEFI CA disabled by default who isn't disabling untrusted DMA-capable buses is selling snakeoil, and the ones who do aren't obtaining meaningful additional security by doing so. Some of the buses that haven't been whitelisted are only internal, so technically not snakeoil, just won't let you auto-enable encryption.
- 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.

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

by mjg59 4y ago

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

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.
        mjg59 4y ago
        Systems have been shipping for years without any untrusted DMA-capable buses (source: I audited a bunch of this in a large enterprise). Anyone who's currently shipping systems with the 3rd Party UEFI CA disabled by default who isn't disabling untrusted DMA-capable buses is selling snakeoil, and the ones who do aren't obtaining meaningful additional security by doing so.
        Avamander 4y ago
        > Systems have been shipping for years without any untrusted DMA-capable buses (source: I audited a bunch of this in a large enterprise) That's your mistake here, you saw it in a large enterprise, the context is "average user". > 3rd Party UEFI CA disabled by default who isn't disabling untrusted DMA-capable buses is selling snakeoil, and the ones who do aren't obtaining meaningful additional security by doing so. Some of the buses that haven't been whitelisted are only internal, so technically not snakeoil, just won't let you auto-enable encryption.
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.