Nearly Every Windows and Linux Device Vulnerable To New LogoFAIL Firmware Attack (arstechnica.com) 69
"Researchers have identified a large number of bugs to do with the processing of images at boot time," writes longtime Slashdot reader jd. "This allows malicious code to be installed undetectably (since the image doesn't have to pass any validation checks) by appending it to the image. None of the current secure boot mechanisms are capable of blocking the attack." Ars Technica reports: 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 vulnerabilities are the product of almost a year's worth of work by Binarly, a firm that helps customers identify and secure vulnerable firmware. The vulnerabilities are the subject of a coordinated mass disclosure released Wednesday. 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. The researchers unveiled the attack on Wednesday at the Black Hat Security Conference in London.
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. "Once arbitrary code execution is achieved during the DXE phase, it's game over for platform security," researchers from Binarly, the security firm that discovered the vulnerabilities, wrote in a whitepaper. "From this stage, we have full control over the memory and the disk of the target device, thus including the operating system that will be started." From there, LogoFAIL can deliver a second-stage payload that drops an executable onto the hard drive before the main OS has even started. The following video demonstrates a proof-of-concept exploit created by the researchers. The infected device -- a Gen 2 Lenovo ThinkCentre M70s running an 11th-Gen Intel Core with a UEFI released in June -- runs standard firmware defenses, including Secure Boot and Intel Boot Guard. LogoFAIL vulnerabilities are tracked under the following designations: CVE-2023-5058, CVE-2023-39538, CVE-2023-39539, and CVE-2023-40238. However, this list is currently incomplete.
"A non-exhaustive list of companies releasing advisories includes AMI (PDF), Insyde, Phoenix, and Lenovo," reports Ars. "People who want to know if a specific device is vulnerable should check with the manufacturer."
"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. It's also a good idea, when possible, to configure UEFIs to use multiple layers of defenses. Besides Secure Boot, this includes both Intel Boot Guard and, when available, Intel BIOS Guard. There are similar additional defenses available for devices running AMD or 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. 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. "Once arbitrary code execution is achieved during the DXE phase, it's game over for platform security," researchers from Binarly, the security firm that discovered the vulnerabilities, wrote in a whitepaper. "From this stage, we have full control over the memory and the disk of the target device, thus including the operating system that will be started." From there, LogoFAIL can deliver a second-stage payload that drops an executable onto the hard drive before the main OS has even started. The following video demonstrates a proof-of-concept exploit created by the researchers. The infected device -- a Gen 2 Lenovo ThinkCentre M70s running an 11th-Gen Intel Core with a UEFI released in June -- runs standard firmware defenses, including Secure Boot and Intel Boot Guard. LogoFAIL vulnerabilities are tracked under the following designations: CVE-2023-5058, CVE-2023-39538, CVE-2023-39539, and CVE-2023-40238. However, this list is currently incomplete.
"A non-exhaustive list of companies releasing advisories includes AMI (PDF), Insyde, Phoenix, and Lenovo," reports Ars. "People who want to know if a specific device is vulnerable should check with the manufacturer."
"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. It's also a good idea, when possible, to configure UEFIs to use multiple layers of defenses. Besides Secure Boot, this includes both Intel Boot Guard and, when available, Intel BIOS Guard. There are similar additional defenses available for devices running AMD or ARM CPUs."
Exaggerated headline (Score:2)
Almonst none of our Linux devices uses UEFI and I believe this is true also for Android phones.
Re: (Score:2)
Hint: We are not in the PC market
Re: (Score:3)
Well, I could imagine people wanting to attack routers. Or many NASes.
Re: (Score:1)
RedHat variants like AlmaLinux and Rocky Linux do, so RedHat would too. I think that any business with an IT department, (or contractor IT) would use it, although I've met IT contractors who couldn't put batteries in a flashlight correctly. Thankfully, I've been retired for over eight years, so I don't have to deal with this other than the four Windows and two Linux computers here.
Re: (Score:2)
Re: (Score:3)
Obviously linux devices that aren't UEFI booted, or devices that have SecureBoot disabled aren't any more vulnerable than they ever were.
Uefi ufia (Score:2)
That's me new headline! Or should be
Re: (Score:3)
I sure wish Arm devices would use UEFI. Or at least standardize on a boot loader that can easily boot from any storage source. I'm really tired of dealing with Arm SBCs where every board uses a slightly different version of u-boot, and some can boot USB, and others can't. I have an Orange Pi5 which is very capable, but by default it only boots the sdcard. I have to first write and sdcard image, then use that to write an image to an M.2 drive, and then flash u-boot with a new version and probably some ste
Re: (Score:2)
Yeah this can be a collossal pain in the arse when evaluating sbc's and dev boards.
Unfortunately the ARM world hasnt really had the massive standardizing forces of nature that where IBM and Microsoft behind them (And Apple aint interested at all in sharing its toys).
Really Arm needs to sit down with the major OEMs and set up some standards for hardware, boot, firmware, etc.
Re: (Score:2)
UEFI wouldn't help your issue. You still need a device driver within the boot/bios (e.g. uboot) that can boot off the given device. On smaller systems, there may be limited EPROM, so adding a bunch of drivers doesn't make sense. And, as a workaround, you can image the SD card with whatever second stage boot loader you want, with whatever capabilities you want (similar to grub), so you needn't reflash the boot/bios.
Re: (Score:2)
Doesn't worry me (Score:2)
I used to write UEFI drivers and I'm not surprised that these problems have only now been discovered. This is one of the reasons that I'm running a MacBook Pro as my daily driver. It has a completely different boot setup although still based on EFI.
Re: (Score:2)
This seems like an extremely easy to avoid exploit: simply don't load random files from the internet into your BIOS. Switching to a mac where you don't have the ability to do something you're not doing anyway seems like overkill.
And honestly the fact that this exploit exists shouldn't surprise us, I remember doing a few security updates for image processing libraries over the past couple years, of course BIOSes aren't updated for this.
This is great news! (Score:5, Funny)
Now I don't have to dual-boot to choose between which vulnerabilities I'm affected by!
Windows Used for 3D Solids Modeling (Score:3, Interesting)
I was actually laughed out of a discussion when I noted My Dell laptop was only on the Internet one time to download my CAD software and I never put it on the Internet again. All data moves out via removable media to my MacBook Pro. Nothing is perfect, but at least I take reasonable precautions.
Re: (Score:3)
Not that you're a likely target but there are all sorts of attacks designed for attacking no-net computers. Some of the work in that field is brilliant. I suggest you take a few minutes to see some of the work published there.
Re:Windows Used for 3D Solids Modeling (Score:4, Interesting)
According to the news, Dell laptops are immune to this particular attack. It nvolves changing the logo image in UEFI, which Dell configures to be disallowed, like "Many OEM" https://www.tomshardware.com/p... [tomshardware.com]
Re: (Score:2)
A lot of the work in that field involves either audio attacks of some sort where keyboard clicks get picked up or some really cool shit analyzing things like power use fluctuations and fan noise.
Dell is not immune to those.
Re:Windows Used for 3D Solids Modeling (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: Windows Used for 3D Solids Modeling (Score:2)
Re: (Score:3)
note that for this exploit to work the machine has to be already seriously compromised. this can be achieved over the network or with physical access too: make sure that that removable media of yours is *always* perfectly clean, ideally use only brand new ones and discard them after use, and that you never ever leave that laptop unattended, not even for a second. don't hesitate to even carry it with you to the toilet ... and let those fools keep laughing at their heart's content ...
Re: (Score:2)
Brand new ones are probably more of a risk than one you keep safe yourself. It wouldn't be the first time that new memory devices have been found to have malware from the factory.
Back in the day I used to buy HD floppy disks and wipe them with a tape eraser, basically an electromagnet. As well as erasing any pre-installed malware, it also helped them work better in DD drives. I don't know if tape erasers are effective on flash media.
Re: (Score:3)
Re: (Score:2)
Very interesting, thanks. So basically it's almost impossible to buy a flash drive that you can be sure doesn't have malware on it. I suppose even if you could erase the flash memory, the controller firmware could have malware in it anyway.
There was something to be said for back when disks, even hard disks, were basically dumb devices with no intelligence of their own. A floppy drive and early HDDs basically connect the magnetic read/write head to the computer, with just a bit of signal conditioning in-betw
Re: (Score:3)
Your situation is probably still "laughable":
-If you air gap a modern system but still actively move data back and forth via USB key, it's almost certain you aren't keeping up with security updates. I would argue that's a far bigger risk than having network connectivity, if you are still subjecting the system to new data via USB key.
-Your assumption that your Dell is more vulnerable to this than your Mac is likely misplaced. Given the breadth of the disclosures, it seems it would be in Tiano Core UEFI cod
Re: (Score:2)
Probably because you are overly paranoid. Its highly likely you are a low risk target and since you don't use that device for online banking/shopping/transactions it would make you an even lower risk. And since its a CAD computer I suspect there is a zero chance there are also nuclear secrets being held on that device.
I wonder if you live in the US where 95% of households have unprotected windows that any hobo can throw a rock through and gain access. If so, which has a greater risk of compromise; a compute
Wait, what??? (Score:3)
BIOS / UEFI code is a dumpster fire? Say it ain't so!!!
The code to Armageddon will be (Score:3, Funny)
...hidden in porn.
Quiet Boot = Off (Score:4, Interesting)
I usually turn off boot logos first thing so I can see what the heck went wrong when it does.
Normies find text scrolling by to be frightening, though.
I guess strangers are flashing their BIOS updates?
Re:Quiet Boot = Off (Score:4, Interesting)
I guess strangers are flashing their BIOS updates?
UEFI can be updated blindly from any software running as root / admin. It's been a long time since flashing a BIOS was something complicated. The attack vector here is the same as any administrative based virus.
Re: Quiet Boot = Off (Score:4, Informative)
Re: (Score:2)
Many systems don't even have an option to disable the logo now, or at least not without also turning off fast booting. They still show error messages if things go wrong, but in the normal course of things there is no need.
Most of the text that was being shown is no longer produced anyway - the UEFI doesn't need to configure hardware prior to the OS loading any more. It was a waste of time, the OS would load its own drivers and the user would have to wait longer. A legacy of the DOS days when hardware was ac
"Secure" Boot is DRM, not system security (Score:5, Insightful)
Secure Boot only serves to restrict you. A competent attacker that has physical access could get around it all along. And that is what the attacker likely needs for this attack as well.
Incidentally, I find these logos annoying and have them all turned off.
Re: (Score:2)
Same. Always have disabled the logo, it hides boot info. Presumably this setting also removes the attack vector.
Re:"Secure" Boot is DRM, not system security (Score:4, Informative)
Same. Always have disabled the logo, it hides boot info. Presumably this setting also removes the attack vector.
If someone has the ability to upload a new logo they have the ability to enable the logo. Don't run unknown software as an admin. Don't blindly elevate privileges. Don't leave the UEFI access password-unlocked. There, we just solved 99% of UEFI / Boot related attacks on your system.
Re: (Score:2)
Same. Always have disabled the logo, it hides boot info. Presumably this setting also removes the attack vector.
If someone has the ability to upload a new logo they have the ability to enable the logo.
Somebody that has those abilities has already compromised the system. Your logic is broken.
Re: (Score:2)
No it's not. There's a difference between someone having access to your system at a point in time, and someone having access to your system at a later date in a way that survives you even throwing out your HDD and replacing it with another.
Don't downplay the importance of what we used to call boot sector attacks.
Re: (Score:3)
That's just not true. You can remove any factory installed keys and generate your own key and sign your bootloader, and it is indeed a huge boost in security.
Re: (Score:1)
Ah, denial. Revel in it, because it is all you got here. No, "Secure" Boot does not actually boost _your_ security at all.
Re: (Score:2)
It's not denial, it's speaking from experience. Secure boot absolutely does boost__my__ security if utilized correctly.
Perhaps you don't really understand how it works? Ignorance and fear are often intertwined.
Re: (Score:1)
That's just not true. You can remove any factory installed keys and generate your own key and sign your bootloader, and it is indeed a huge boost in security.
You're describing what Microsoft currently allows on one platform, 64-bit Intel, because there would be too much pushback if they stopped doing so. Later platforms sold with Windows, like ARM, are not unlockable.
There's no requirement that any company provide an unlockable secure boot implementation.
Re: (Score:2)
Well yeah if it wasn't unlockable that's a huge issue...at the moment it is so I appreciate and use it.
Re:"Secure" Boot is DRM, not system security (Score:4)
That's simply not true. Secure Boot allows you to verify that your OS is not compromised. Even with this attack, it is possible to mitigate it simply by requiring user interaction or a password before allowing the UEFI to be written.
Secure Boot is not invincible, but it does stop a lot of malware that used to plague systems, and prevents a lot of low skill attacks that require physical access. This particular attack requires the OS to already be compromised to the point where malware can write the UEFI, i.e. it a chain of multiple vulnerabiltiies.
I'm old enough to remember back in the 90s when malware simply zeroed your BIOS, or in the 2010s when it replaced the Windows NTFS driver with one that hid the malware files from anti-virus software and ran your OS in its own sandbox. Secure Boot put an end to all that, which is why malware switched to ransomware and browser exploits.
Re: (Score:2)
No, "Secure" Boot does not allow _you_ to do anything.
Re: (Score:2)
Mine did. I was able to install my own certificate in the Secure Boot store, and use it to bootload a mini Linux system that does nothing but run sedutil to unlock my drives.
Re: (Score:2)
Re: (Score:2)
Pretty hard to claim that. Microsoft signed, using their own key (i.e., one that is built into every OEM machine) a piece of open-source code. Every Linux distribution has a copy of the boot shim signed with Microsoft's key. The shim is designed to be a piece of simple boot code that was audited for security and could be used to securely boot something else signed with your own key. Many Linux distributions already do this - the shim boots a uniquely signed copy of GR
The POC shows admin access (Score:2)
AT that stage couldn't you just flash a compromised firmware instead of fiddling around with a logo?
Or can this flash a logo to any UEFI? Having a different logo show up might set off a user?
Re: (Score:2)
The firmware is signed by the vendor (and normally only signed/validated firmware can be installed). The logos can be replaced unsigned (because they're just an image, right?), since they're often replaced by resellers and such.
Doesn't need admin access (Score:2)
The boot process is supposed to only execute trusted (signed) things. But along the way the trusted things go out and display a logo. The logo isn't supposed to be an executable so it didn't require any level of trust. Worse a process that has low privileges might be able to replace the logo. A user could be tricked into putting a new cool logo on their computer and because they
Goddamn APT risks due to over-engineering (Score:3)
Nearly Every Windows and Linux Device Vulnerable (Score:2)
But FreeBSD is safe!! Yay! I've always been saying that BSD is going to rule the world.
Seriously, why such a misleading title? The OS has nothing to do with this vulnerability.
just a reminder (Score:3)
There was once a very reliable and unhackable way to boot a PC. It was called a "BIOS" and was stored in a PROM, ROM, or EPROM which was not alterable in-system. Eventually this was replaced on some systems with the same code in EEPROM or Flash memory, with a jumper to enable in-circuit alteration when the owner of the system physically enabled it but not at any other time.
Then, Microsoft decided to demand all PCs be made "secure" (and old ones obsoleted to force everybody to buy newer versions of Windows) and everybody was force-fed the amazing and perfect UEFI. This cannot be happening now, because we all have UEFI and we were told it is more secure than a boot ROM and nobody would ever LIE to us in order to make more money would they???
This can't be fixed for a lot of Windows machines (Score:2)
Back when Windows 10 first raised its ugly head, Microsoft enabled upgrading from Windows versions 7, 8 and 8.1. They only stopped permitting this around a month ago. Upgrading from Windows 10 to 11 (or in the other direction) apparently still works, but hardly any older machines support Windows 11 anyway so that is rather irrelevant in this context.
What is relevant is changing certain hardware components breaks the Windows key, and - as of a few weeks ago - if it is an "upgrade key" then it is no longer
A process is trusted if and only if (Score:2)
1 bug free
2 output only trusted data
If you go through your system and just mark each process as trusted if it meets these requirements you will find all kinds of bad assumptions.
nearly every? (Score:2)
Even among uefi, the article I read said that [most?] Dell devices are not susceptible because the logo can't be changed.
So this definitely sounds ridiculous (Score:2)
If the firmware was designed correctly, this shouldn't happen. They said they put the boot logo on the ESP - on the boot drive. What firmware designer thinks they should be able to trust ANYTHING external to the firmware itself? One of the variants of the exploit puts it into an unsigned area of the EFI. But why is that even a thing? It should reject anything that isn't signed with the vendor key unless you disable secure boot and explicitly allow it.
They literally created this vulnerability specifical
Re: (Score:2)
It's not just that. These are clearly buffer overflow bugs. Static checkers should be able to pick those up, as it's a very common class of vulnerability. QA should also have picked up such issues gif the same reason - it's a class of defect that is well-known.
This tells us that many UEFI development firms haven't invested in any static code checking tools and aren't investing in QA.
When firms do that, you know there'll be a lot of defects.
Re: (Score:2)
Right - they maintained the code as if it would only ever decode pre -approved trusted images. This means custom images should never have been allowed.