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?
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!”
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?
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
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.
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]
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.
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.
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?
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)
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?
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.
It's rare that I get to feel anything remotely comforting about not being able to afford new hardware, but if I understand correctly, my BIOS-only dinosaur can't be exploited.
Still vulnerable to thousands of other exploits no doubt, but not this one.
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?
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?
Yes, it can execute code regardless of OS installed because it persists on the Mainboard and loads before any OS, making it possible to inject code into any OS.
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?
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?)
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: 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.
You may be surprised to learn that they didn’t all run out until 2013. UEFI had been around for 7 years by this time, and Microsoft was doing patent enforcement actions against Tom Tom during this time period.
Sure, they’re expired now, but not at the time. It was supposed to be an open standard at the time.
Hello I am writing the firmware for MotherBoard 2021, a definitely completely different product than MotherBoard 2020, I am going to ship in in 2 weeks for Christmas, and I am going to write an image decoder on top of bare metal, and it is “not” going to let you hack the pants off the computer.
arstechnica.com
Oldest