3 ms·

>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 researc

>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
        vladvasiliu 2y ago
        But that relies on having the private key available locally, so it doesn't help with the scenario discussed here. Ideally, you'd want to sign the image on a different machine than the one booting it.
        cookiengineer 2y ago
        True, but that kind of also requires some way of distributing the bootable binaries, e.g. via netboot image via a TFTP server. I usually store these keys on a LUKS encrypted flash drive. Not the best opsec, but at least good enough to prevent this kind of malware from spreading around. Can't update the kernel without the flash drive though :D
      - jeroenhd 2y ago
        Unfortunately, using your own keys is a massive pain because it involves the command line. Nobody made good user-friendly tooling for it yet, though the systemd tooling has improved things a lot, but it's not in a place where it can be part of the normal install wizard just yet.
    - deleted 2y ago
      [deleted]

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
        vladvasiliu 2y ago
        But that relies on having the private key available locally, so it doesn't help with the scenario discussed here. Ideally, you'd want to sign the image on a different machine than the one booting it.
        cookiengineer 2y ago
        True, but that kind of also requires some way of distributing the bootable binaries, e.g. via netboot image via a TFTP server. I usually store these keys on a LUKS encrypted flash drive. Not the best opsec, but at least good enough to prevent this kind of malware from spreading around. Can't update the kernel without the flash drive though :D
    - jeroenhd 2y ago
      Unfortunately, using your own keys is a massive pain because it involves the command line. Nobody made good user-friendly tooling for it yet, though the systemd tooling has improved things a lot, but it's not in a place where it can be part of the normal install wizard just yet.
  - deleted 2y ago
    [deleted]