redcalcium,

As its name suggests, LogoFAIL involves logos, specifically those of the hardware seller that are displayed on the device screen early in the boot process, while the UEFI is still running.

Me using an old PC with BIOS instead of UEFI: 😏

ryannathans,

Also known as using a pc with unpatched cpu vulnerabilities

kugmo,
@kugmo@sh.itjust.works avatar

gigachads use mitigations=off anyways

ryannathans,

Makes it go fast

TheCaconym,

BIOS booting stays winning

Yewb,

Fyi if someone had physical access / administration access due to another vulnerability to your machine they can exploit it, news at 11:00

sadreality,

Would resetting bios clear this?

fl42v,

More like reflashing entirely or just changing the image. Alternatively, you can often disable showing the.logo somewhere in the settings.

What’s known as resetting bios is more like removing the stuff saved in CMOS, AFAIK

Nyfure,

Most fastboot options dont show the logo until windows bootloader comes along.
Though i am not sure how or why the logo is displayed when windows loads? Is that the same image? Loaded and displayed again or just didnt clear the display?

binboupan,

Loaded and displayed again, yes. It is stored in the BGRT table.

ShittyBeatlesFCPres,

I can’t believe stupid, pointless marketing crap didn’t have the best of the best working to ensure security.

charonn0,
@charonn0@startrek.website avatar

As its name suggests, LogoFAIL involves logos, specifically those of the hardware seller that are displayed on the device screen early in the boot process, while the UEFI is still running. Image parsers in UEFIs from all three major IBVs are riddled with roughly a dozen critical vulnerabilities that have gone unnoticed until now. By replacing the legitimate logo images with identical-looking ones that have been specially crafted to exploit these bugs, LogoFAIL makes it possible to execute malicious code at the most sensitive stage of the boot process, which is known as DXE, short for Driver Execution Environment.

So, does disabling the boot logo prevent the attack, or would it only make the attack obvious?

lol, (edited )
@lol@discuss.tchncs.de avatar

deleted_by_author

  • Loading...
  • charonn0,
    @charonn0@startrek.website avatar

    Usually you can, though the setting might be listed under something like “show diagnostic during boot”.

    lazylion_ca,

    If you have access to replace the logo file, you probably have access to enable it as well.

    fl42v,

    Not necessarily, I guess. They’re talking about a firmware upgrade of sorts, and, at least on the machines I own(ed), performing it didn’t reset user settings (which disabling the logo is)

    0x0,

    I wonder if old BIOS are vulnerable…

    admin,
    @admin@lemmy.my-box.dev avatar

    Nope, they aren’t as universal as EFI. I think the closest comparable attack vector for “old tech” is a bootsector virus.

    _edge,

    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?

    blindsight, (edited )

    The idea is also that a compromised system will remains compromised after all storage drives are removed.

    Ithorian,
    @Ithorian@hexbear.net avatar

    So if I have my computer set that it needs a sudo password for most changes am I good?

    fl42v,

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

    _edge,

    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.

    Ithorian,
    @Ithorian@hexbear.net avatar

    Thanks for the answer. Unless my dog learns how to code I think I’m safe from anyone getting physical access

    PhatInferno,
    @PhatInferno@midwest.social avatar

    As a hacker imma start teaching dogs to code as part of my breakin process, sorry bud

    FigMcLargeHuge,

    Introduce him or her to FidoNet.

    Murdoc,

    Ah, so the next Air Bud movie will be what, Hack Bud?
    “There’s nothing in the specifications that says that a dog can’t have admin access.”
    “Nothing but 'net!”

    timicin,

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

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

    InnerScientist,

    replace a file on the EFI partition.

    Doesn’t this mean that secure boot would save your ass? If you verify that the boot files are signed (secure boot) then you can’t boot these modified files or am I missing something?

    hottari,

    If I can replace a file in your EFI, how hard would it be to sign the same file.

    InnerScientist,

    Well, it rules out an evil maid attack and maybe jumping over a dual boot setup.

    fl42v, (edited )

    If it can execute in ram (as far as I understand, they’ve been talking about fileless attacks, so… Possible?), it can just inject whatever

    Addit: also, sucure boot on most systems, well, sucks, unless you remove m$ keys and flash yours, at least. The thing is, they signed shim and whatever was the alternative chainable bootloader (mako or smth?) effectively rendering the whole thing useless; also there was a grub binary distributed as part of some kaspersky’s livecd-s with unlocked config, so, yet again, load whatever tf you want

    InnerScientist,

    Last time I enabled secure boot it was with a unified kernel image, there was nothing on the EFI partition that was unsigned.

    Idk about the default shim setup but using dracut with uki, rolled keys and luks it’d be secure.

    After this you’re protected from offline attacks only though, unless you sign the UKI on a different device any program with root could still sign the modified images itself but no one could do an Evil Maid Attack or similar.

    fl42v,

    The point with m$ keys was that you should delete them as they’re used to sign stuff that loads literally anything given your maid is insistent enough.

    [note: it was mentioned in the arch wiki that sometimes removing m$ keys bricks some (which exactly wasn’t mentioned) devices]

    _edge,

    Well, not an expert. We learned now that logos are not signed. I’m not sure the boot menu config file is not either. So on a typical linux setup you can inject a command there.

    peopleproblems,

    See, I knew there were other reasons I wouldn’t touch secure boot lol

    falsem,

    Yeah, if someone has write access to your boot partition then you're kind of already screwed.

    plinky,
    @plinky@hexbear.net avatar

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

    _edge,

    This is also my understanding, at least of you keep the EFI partition.

    Bitrot, (edited )
    @Bitrot@lemmy.sdf.org avatar

    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.

    Bipta,

    Boy do I love the future.

    Bitrot,
    @Bitrot@lemmy.sdf.org avatar

    It’s reminiscent of boot sector viruses in the DOS days.

    plinky,
    @plinky@hexbear.net avatar

    damn 😱

    redd,
    @redd@discuss.tchncs.de avatar

    Don’t panic!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • linux@lemmy.ml
  • localhost
  • All magazines
  • Loading…
    Loading the web debug toolbar…
    Attempt #