FYI: The blog post by binarly is a cleaner source and was published a whole week ago.
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 643 words, the summary contains 232 words. Saved 64%. I’m a bot and I’m open source!
executes malicious firmware early in the boot-up sequence,
Isn’t the system already infected then?
Any patches?
The best way to prevent LogoFAIL attacks is to install the UEFI security updates that are being released as part of Wednesday’s coordinated disclosure process. Those patches will be distributed by the manufacturer of the device or the motherboard running inside the device.
Supposedly today? Depends on the manufacturer
No. Every vendor is going to need to patch their shit, so most likely the OS’s are going to kludge something on top to try to prevent uploading logos.
So, this is proof of concept, not an actual attack at this time. Correct?
No, it’s an actual attack. But we don’t know for sure if it’s being exploited actively in the wild. This vulnerability has existed ever since PCs adopted UEFI (~2006).
More importantly, does the attacker need physical access to the computer or can this be performed over the Internet/local network?
I’ll answer because I found the information. It appears that the attacker would need to rely on physical access to the machine OR another exploit that lets them access the computer remotely.
So the best security is still keeping your computer behind a locked door and not clicking on suspicious stuff?
The best security is keeping it in box, removing the battery, and never turning it on. /j
Maybe I should hire an Amish guy as a consultant for IT. Those guys never get hacked.
Beg to disagree. See: “Amish Mafia.”
Or they could just get you to execute the command without your knowledge (eg: all the people who just blindly copy-paste commands, or pipe scripts from the net into
sudo). Or it could be a compromised github account/repo (supply-chain attack). Or even the ol’ techsupport scam where they get gullible users to install stuff…
They need to be able to place a malicious file in EFI boot partition or in an unsigned section of a firmware update. Holes in the libraries that parse images for display on preboot.
What if I disable UEFI splash screen? I always do that if possible. Not due to this, but because I prefer a bunch of text over a lame logo.
No way to know. It depends on how whoever did your firmware handled it. The idea is that there’s an overflow or something in the image parser. If the person writing your firmware code still parses the image even if it’s not displayed, you’d still get the pointy end. (and at that point, they’re bypassing secure boot)
Don’t sweat it too much, the file has to get there somehow before it can even be an issue. So someone needs to write to your UEFI partition or get you to flash a bad bios. It’s just an inside vector not a direct attack. I’ll be good for people to update their damn image processing, but the likely hood of getting shived in the wild is pretty low.
I wonder… could one put their UEFI partition on a flash drive, then remove after booting? Or just dismount the partition, but physical separation sounds better
How do you fuck up a bitmap parser? It’s an array. There’s no metadata. You allocate the filesize!
It’s all fun and games until the user has bit rot or some stupid thing is offset by one or a row doesn’t exist somewhere and you have to correct for it
A corrupted bitmap should only look ugly. There is no decoding or compression - only translation, and sometimes not even that.
A bitmap is the platonic ideal of a buffer overrun being comically obvious and trivially preventable.
