Last Tuesday, loads of Linux users—many running packages released as early as this year—started reporting their devices were failing to boot. Instead, they received a cryptic error message that included the phrase: “Something has gone seriously wrong.”

The cause: an update Microsoft issued as part of its monthly patch release. It was intended to close a 2-year-old vulnerability in GRUB, an open source boot loader used to start up many Linux devices. The vulnerability, with a severity rating of 8.6 out of 10, made it possible for hackers to bypass secure boot, the industry standard for ensuring that devices running Windows or other operating systems don’t load malicious firmware or software during the bootup process. CVE-2022-2601 was discovered in 2022, but for unclear reasons, Microsoft patched it only last Tuesday.

The reports indicate that multiple distributions, including Debian, Ubuntu, Linux Mint, Zorin OS, Puppy Linux, are all affected. Microsoft has yet to acknowledge the error publicly, explain how it wasn’t detected during testing, or provide technical guidance to those affected. Company representatives didn’t respond to an email seeking answers.

  • Possibly linux
    link
    fedilink
    English
    arrow-up
    31
    ·
    3 months ago

    It is fine if you only accept signatures from yourself. However, that’s a lot of work as you need to sign everything.

    • delirious_owl@discuss.online
      link
      fedilink
      arrow-up
      18
      arrow-down
      1
      ·
      3 months ago

      Good luck replacing the PKI on your system’s Secure Boot firmware. Most platforms probably don’t support it and have no documentation

    • Norah - She/They@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      4
      ·
      3 months ago

      How is it a lot of work? There’s generally one sig you have to add on installing a new OS. Sometimes, rarely, one for a new kernel module. It’s not like you sign every single package you boot.

      • Possibly linux
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 months ago

        Still takes work. You also need to disable all other keys if you want it to matter in terms of security.

        • Norah - She/They@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          3
          ·
          3 months ago

          What are you talking about with “disabling all other keys”? You don’t need to do this at all. You’re seriously making a mountain out of a molehill.

          • Possibly linux
            link
            fedilink
            English
            arrow-up
            6
            arrow-down
            1
            ·
            3 months ago

            Why wouldn’t you disable other keys? If anyone can boot anything why use secure boot?

            • Norah - She/They@lemmy.blahaj.zone
              link
              fedilink
              English
              arrow-up
              4
              ·
              edit-2
              3 months ago

              I think you’re misunderstanding the purpose of Secure Boot. It’s not designed, nor very good at, preventing physical access. It’s designed to verify the authenticity of the code you are booting each time, most generally to prevent remote attacks. Think of it more like how HTTPS works. The reason you commonly have to install new keys when installing Linux is because there are separate ones for the bootloader, the OS, and kernel modules. GRUBs is generally already in the database. The OS can be hit and miss, Canonical generally has theirs included for example. Then there’s the kernel modules. If they were built and included in binary form, they’re usually signed with the same key as the OS. But if they’re built locally, say when you install NVIDIA driver’s, then they’re signed with a local key, which has to be enrolled. So it’s similar to a self-signed HTTPS certificate. A lot of routers use those, and browser’s will throw a big warning you have to click through. It’s the same with Secure Boot. For example, if a virus tries to build a malicious kernel module, it will throw the same enrollment screen, which would let you know something’s up if you didn’t initiate it. There also has to be a password, that you set in userspace, and then re-enter on the enrollment screen, confirming that it’s a requested action.

              Disabling other keys won’t prevent someone from simply entering the bios and disabling Secure Boot first if they have physical access, which would let them boot anything. If you want to prevent that, then the methods you would generally use is setting a system password in the BIOS it asks for each boot, or disabling other boot options (or the boot menu depending on the computer) and setting a BIOS password. However, if you’re trying to prevent people from booting other OSes as a way to protect your files from being accessed, well someone could just take the drive out with physical access. The best practice there is to encrypt the drive with something like BitLocker, FileVault or LUKS/dm-crypt (basis of many distros full-disk encrypt features).

              Edit: You could also have Secure Boot enabled, delete every other key and set a BIOS password if you wanted too I guess. I haven’t tried, nor read of anyone trying too.