• _edge@discuss.tchncs.de
    ·
    7 months ago

    There are several ways to exploit LogoFAIL. Remote attacks work by first exploiting an unpatched vulnerability in a browser, media player, or other app and using the administrative control gained to replace the legitimate logo image processed early in the boot process with an identical-looking one that exploits a parser flaw. The other way is to gain brief access to a vulnerable device while it’s unlocked and replace the legitimate image file with a malicious one.

    In short, the adversary requires elevated access to replace a file on the EFI partition. In this case, you should consider the machine compromised with or without this flaw.

    You weren't hoping that Secure Boot saves your ass, were you?

    • plinky [he/him]
      ·
      7 months ago

      The worst part it persists through reinstalls (if i understood correctly)

        • NaN@lemmy.sdf.org
          ·
          edit-2
          7 months ago

          It can outlast those too.

          In many of these cases, however, it’s still possible to run a software tool freely available from the IBV or device vendor website that reflashes the firmware from the OS. To pass security checks, the tool installs the same cryptographically signed UEFI firmware already in use, with only the logo image, which doesn’t require a valid digital signature, changed.

      • _edge@discuss.tchncs.de
        ·
        7 months ago

        Yes, that's my understanding. A normal user cannot do this. (And of course, an attacker shouldn't not control a local user in the first place.)

        Physical access is also a risk, but physical access trumps everything.

      • fl42v@lemmy.ml
        ·
        7 months ago

        Unless they find another way to escalate privileges... A bug, a random binary with suid, etc

    • timicin@lemmygrad.ml
      ·
      7 months ago

      You weren’t hoping that Secure Boot saves your ass, were you?

      i wonder if containerized firefox (eg snap/flatpak) will

  • JakenVeina@lemm.ee
    ·
    edit-2
    7 months ago

    Did anyone really think that making UEFI systems the equivalent of a mini OS was a good idea? Or having them be accessible to the proper OS? Was there really no pushback, when UEFI was being standardized, to say "images that an OS can write to are not critical to initializing hardware functionality, don't include that"? Was that question not asked for every single piece of functionality in the standard?

    • gerdesj@lemmy.ml
      ·
      7 months ago

      Did anyone really think that making UEFI systems the equivalent of a mini OS was a good idea

      UEFI and Secure Boot were pushed forcibly by MS. That's why FAT32 is the ESP filesystem.

      If I had to guess, a brief was drafted at MS to improve on BIOS, which is pretty shit, it has to be said. It was probably engineering led and not an embrace, extinguish thing. A budget and dev team and a crack team of lawyers would have been whistled up and given a couple of years to deliver. The other usual suspects (Intel and co) would be strong armed in to take whatever was produced and off we trot. No doubt the best and brightest would have been employed but they only had a couple of years and they were only a few people.

      UEFI and its flaws are testament to the sheer arrogance of a huge company that thinks it can put a man on the moon with a Clapham omnibus style budget and approach. Management identify a snag and say "fiat" (let it be). Well it was and is and it has a few problems.

      The fundamental problem with UEFI is it was largely designed by one team. The wikipedia page: https://en.wikipedia.org/wiki/UEFI is hilarious in describing it as open. Yes it is open ... per se ... provided you decide that FAT32 (patent encumbered) is a suitable file system for the foundations of an open standard.

      I love open, me.

    • Marxism-Fennekinism@lemmy.ml
      ·
      edit-2
      7 months ago

      It breaks the cardinal rule of executing privileged code: Only code that absolutely needs to be privilaged should be privileged.

      If they really wanted to have their logo in the boot screen, why can't they just provide the image to the OS and request through some API that they display it? The UEFI and OS do a ton of back and fourth communication at boot so why can't this be apart of that? (It's not because then the OS and by extension the user can much more easily refuse to display what is essentially an ad for the hardware vendor right? They'd never put "features" in privileged code just to stop the user from doing anything about it... right?)

  • Marxism-Fennekinism@lemmy.ml
    ·
    edit-2
    7 months ago

    I've never been a fan of the UEFI logo inserting itself into the boot screen. It's basically just an advertisement for the hardware vendor because they're jealous of the OS having the spotlight. And it's an ad that, like so many other ads before it, screws over the security and privacy of the advertisee because fuck you that's why.

    • ddkman@lemm.ee
      ·
      7 months ago

      I don't know. It looks more aesthetically consistent. Your computer has to display something. Average users would be scared if it dumped logs on the display. so the vendor logo makes sense. It COULD just say loading, but this is a bit pedantic I think.

  • const_void@lemmy.ml
    ·
    7 months ago

    We need more machines that support coreboot. These proprietary firmware vendors have been getting rich off making our machines worse for too long.

    • down daemon@lemmy.ml
      ·
      7 months ago

      i use coreboot but i'd prefer libreboot if a gaming level system with linux supported it. Are their any? I ask to the masses, not you specifically lol

  • milicent_bystandr@lemm.ee
    ·
    7 months ago

    So, does this affect dual boot systems, if e.g. Windows is compromised, now that malware in the efi partition can compromise the Linux system next time it boots? Yikes!

    I suppose in principle malware from one OS can attack the other anyway, even if the other is fully encrypted and/or the first OS doesn't have drivers for the second's filesystems: because malware can install said drivers and attack at least the bootloader - though that night have been protected by secure boot if it weren't for this new exploit?

  • buwho@lemmy.ml
    ·
    7 months ago

    is it common practice to have a web browser or media player running with elevated permissions? seems like a strange thing to do...

  • arglebargle@lemm.ee
    ·
    7 months ago

    Is this potentially useful to me? Since it is persistent, can I use it on this motherboard I have over here that insists on using UEFI even if I do not want to?

  • Marxism-Fennekinism@lemmy.ml
    ·
    edit-2
    7 months ago

    The article didn't mention this, but would disabling the UEFI logo in the boot screen mitigate the vulnerability until proper patches get rolled out? (Or honestly at this point, I'd keep it disabled even after it's patched in case they didn't patch it right. UEFI's are all proprietary so it's not like you can check.) Since the vulnerability is in the image parser, would bypassing that be enough?

    Do they even let you disable it?