This is the best summary I could come up with:
Hundreds of Windows and Linux computer models from virtually all hardware makers are vulnerable to a new attack that executes malicious firmware early in the boot-up sequence, a feat that allows infections that are nearly impossible to detect or remove using current defense mechanisms.
The attack—dubbed LogoFAIL by the researchers who devised it—is notable for the relative ease in carrying it out, the breadth of both consumer- and enterprise-grade models that are susceptible, and the high level of control it gains over them.
LogoFAIL is a constellation of two dozen newly discovered vulnerabilities that have lurked for years, if not decades, in Unified Extensible Firmware Interfaces responsible for booting modern devices that run Windows or Linux.
The participating companies comprise nearly the entirety of the x64 and ARM CPU ecosystem, starting with UEFI suppliers AMI, Insyde, and Phoenix (sometimes still called IBVs or independent BIOS vendors); device manufacturers such as Lenovo, Dell, and HP; and the makers of the CPUs that go inside the devices, usually Intel, AMD or designers of ARM CPUs.
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.
LogoFAIL is a newly discovered set of high-impact security vulnerabilities affecting different image parsing libraries used in the system firmware by various vendors during the device boot process.
The original article contains 663 words, the summary contains 232 words. Saved 65%. I’m a bot and I’m open source!
Because there really isn’t one, lol.
By the time an attacker has a write access to your boot permission everything else is kinda fucked already.
This is worse than many, since it persists across reinstalls and even potentially drive swaps, and fools systems such as secure boot.
Yes, an attacker with write access to boot already compromised the entire OS and data. Usually replacing the storage or reinstalling the OS would get rid of the attacker. But this exploit happens early in the boot process, before the OS even loads.
This means the only way to ensure a network remains uncompromised after an attack is physically destroying any infected devices or replacing their mainboard.
There are major benefits to this approach. One is that no executable code ever touches the hard drive, a technique known as fileless malware that hampers detection by antivirus and other types of endpoint protection software. Another benefit: Once the image is in place, it ensures a device remains infected even when an operating system is reinstalled or the main hard drive is replaced.
damn 😱
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?
The worst part it persists through reinstalls (if i understood correctly)
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.
Since the EFI partition is unencrypted, physical access would do the trick here too, even with every firmware/software security measure.
True, but this was the case without this finding, wasn’t it? With write access to the EFI you could replace the boot loader and do whatever you please.
So if I have my computer set that it needs a sudo password for most changes am I good?
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.
Thanks for the answer. Unless my dog learns how to code I think I’m safe from anyone getting physical access
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?
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.
If I can replace a file in your EFI, how hard would it be to sign the same file.
The idea is also that a compromised system will remains compromised after all storage drives are removed.
I wonder if old BIOS are vulnerable…
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?
If you have access to replace the logo file, you probably have access to enable it as well.
