4 ms·

The researchers are keen to note things about this, but also likely want to avoid giving attackers "more ideas", which I feel limits the discussion. Plus, I hig

The researchers are keen to note things about this, but also likely want to avoid giving attackers "more ideas", which I feel limits the discussion. Plus, I highly doubt these attackers don't know everything we should be discussing. This is obviously a low hanging fruit and first PoC implementation. The fact that secure boot can "mitigate" some of this attack right now is mostly due to the attacker being lazy or deploying an unfinished product. The researchers describe this as "unless they install the attackers certificate", which is a nice way of saying that the attacker has not spent much time fishing through DKMS and abusing the keys used for this purpose. There are a lot of systems that are affected by this type of attack because for various purposes they have to sign their own modules. The most common example of this (until extremely recently, sort of) is Nvidia.

0xDEAFBEAD 2y ago
>The fact that secure boot can "mitigate" some of this attack right now is mostly due to the attacker being lazy or deploying an unfinished product. The researchers describe this as "unless they install the attackers certificate", which is a nice way of saying that the attacker has not spent much time fishing through DKMS and abusing the keys used for this purpose. Can you explain, or link to a source explaining this?
- 1oooqooq 2y ago
  if you can add keys and sign things on the fly secure boot doesn't matter. it only protects you from downward payloads. if the one above the one that cares about secureboot is compromised its useless. you're confused because it's sold differently from this.
  - 0xDEAFBEAD 2y ago
    That all makes sense, but is it really that easy for an attacker to add keys? If so, the entire thing seems a little silly.
    - josephcsible 2y ago
      Attackers don't need to add their own keys. They can piggyback off of the key that you added legitimately to get DKMS working.
      - 0xDEAFBEAD 2y ago
        What fraction of Linux laptop users do this? Seems to me that in an ideal world, you would only have to add the public key, and an attacker wouldn't be able to forge a signature without the private key...
        josephcsible 2y ago
        The point of DKMS is to compile kernel modules on the same host where they'll be used, so it needs the private key to be accessible. And isn't DKMS a rather common thing on Linux, e.g., for Nvidia drivers and for VirtualBox?
        NekkoDroid 2y ago
        On Arch most DKMS packages have a separate package that is compiled directly against the stable kernel (and some against the lts kernel). IIRC they all don't support loading with SB though since the keys that are embedded in the kernel for other modules are discarded after the kernel build. This is to say, its not impossible that those can be signed from the distro. Just Arch doesn't.
        cookiengineer 2y ago
        > Arch Check out "sbctl" by Foxboron, it's a UEFI key and signature manager [1] that's pretty nice. But other than that I agree with you there, I wish that upstream kernel builds would be signed by the distro for secureboot usage. Maybe this should be part of the archlinux-keyring package? [1] https://github.com/foxboron/sbctl https://github.com/foxboron/sbctl

0xDEAFBEAD 2y ago

>The fact that secure boot can "mitigate" some of this attack right now is mostly due to the attacker being lazy or deploying an unfinished product. The researchers describe this as "unless they install the attackers certificate", which is a nice way of saying that the attacker has not spent much time fishing through DKMS and abusing the keys used for this purpose. Can you explain, or link to a source explaining this?

1oooqooq 2y ago
if you can add keys and sign things on the fly secure boot doesn't matter. it only protects you from downward payloads. if the one above the one that cares about secureboot is compromised its useless. you're confused because it's sold differently from this.
- 0xDEAFBEAD 2y ago
  That all makes sense, but is it really that easy for an attacker to add keys? If so, the entire thing seems a little silly.
  - josephcsible 2y ago
    Attackers don't need to add their own keys. They can piggyback off of the key that you added legitimately to get DKMS working.
    - 0xDEAFBEAD 2y ago
      What fraction of Linux laptop users do this? Seems to me that in an ideal world, you would only have to add the public key, and an attacker wouldn't be able to forge a signature without the private key...
      - josephcsible 2y ago
        The point of DKMS is to compile kernel modules on the same host where they'll be used, so it needs the private key to be accessible. And isn't DKMS a rather common thing on Linux, e.g., for Nvidia drivers and for VirtualBox?
        NekkoDroid 2y ago
        On Arch most DKMS packages have a separate package that is compiled directly against the stable kernel (and some against the lts kernel). IIRC they all don't support loading with SB though since the keys that are embedded in the kernel for other modules are discarded after the kernel build. This is to say, its not impossible that those can be signed from the distro. Just Arch doesn't.
        cookiengineer 2y ago
        > Arch Check out "sbctl" by Foxboron, it's a UEFI key and signature manager [1] that's pretty nice. But other than that I agree with you there, I wish that upstream kernel builds would be signed by the distro for secureboot usage. Maybe this should be part of the archlinux-keyring package? [1] https://github.com/foxboron/sbctl https://github.com/foxboron/sbctl