• fubarx@lemmy.ml
    link
    fedilink
    English
    arrow-up
    9
    ·
    4 months ago

    The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text.

    It’s like installing a top-of-the-line alarm system for your house with camera, motion detector, alarm, and immobilizing gas, then leaving the unlock password on a PostIt under the welcome mat.

  • j4k3@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    4 months ago

    K-rapy garboge!:

    There’s little that users of an affected device can do other than install a patch if one becomes available from the manufacturer.

    Gentoo gives extensive instructions:

    Arch:

    NIST (US government guides cover POSIX/Windows with a layperson explanation and guide):

    The technical documentation about Secure Boot says that SB is not a mechanisms to steal ownership of your device. It is a spurious claim because the design specification is only a reference and not a requirement. Gentoo has further documentation that can be found describing KeyTool, a package that enables booting directly into UEFI to change the keys manually if your implemented UEFI bootloader lacks the functional implementation required to sign your own keys. I’ve never tried it personally. I merely know of its existence.

  • tal@lemmy.today
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    4 months ago

    “It’s a big problem,” said Martin Smolár, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. “It’s basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically… execute any malware or untrusted code during system boot. Of course, privileged access is required, but that’s not a problem in many cases.”

    I mean, I don’t really have much interest in requiring that my BIOS code be signed, but I have a hard time believing that this Martin Smolár guy is correct. Just entirely disable firmware updates in the BIOS, and re-enable just for the one boot where you update your BIOS while booting off a trusted USB key. You’d never put your OS in a position of being able to push an update to the BIOS.

    EDIT: Actually, if current BIOSes can update without booting to an OS at all, just selecting a file on a filesystem that they can understand – IIRC my last Asus motherboard could do that – you never need to enable it for even that.

    • SzethFriendOfNimi@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 months ago

      I think Secure boot is intended to check that the boot loader itself is signed.

      This is a way to mitigate viruses and malware that infects the boot loader so it can reinstall itself if it’s removed by AV, or something else.

      If you can create a boot loader that is signed in such a way that secure boot can’t tell it’s invalid then you can do some nasty stuff.

      Closest analogy I can think of is verisigns private key being leaked and there’s no fast and easy way to revoke and replace it without wreaking havoc on currently installed OS’s machines.