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.
Insyde’s security advisory on the vulnerability is here.
I very much hope that Framework’s new arrangements with Insyde on firmware updates will actually bear fruit soon - but as a 12th-Gen owner, I have to say that I am not exactly optimistic…
I posted a link to an article about this yesterday. As I understand it the attacker would need physical access to the device to change the logo, so the danger is pretty low, though not negligible.
The Ars Technica article actually says that one possible vector of attack is remote:
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.
However I think I can still assume that it requires administrative (root) privileges to actually access the logo and change it.
So, one exploit to run arbitrary code, one to elevate permissions in order to install this exploit? Sounds like the kind of thing state actors would resort to as it seems like an awful lot of work for your run of the mill ransomware extortion campaign.
If you don’t run the code yourself, that is.
Bypassing the UAC (admin prompt) on Windows is real, there are several techniques that can be used, unless you set UAC to the highest option “Always notify me” - therefore a code running on your computer can elevate to admin, and persist.
Therefore, running as a regular user without admin rights is always preferred.
It seems like there’s a few ways that OEMs can produce vulnerable firmwares that load unverified logo data. What I’d hope for at this point is a statement from Framework about vulnerable firmware(s) and a timeline for any mitigations.
(EDIT: This was a longer post before I realised there’s a few ways firmware can be vulnerable.)
a new attack has been published with almost every Linux & Windows device being vulnerable at the UEFI level, Insyde is specifically mentioned (which Framework uses)
I posted a link to an article about this yesterday. As I understand it the attacker would need physical access to the device to change the logo, so the danger is pretty low, though not negligible.
This is remote-exploitable, via any other exploit that provides elevated operating system privileges.
The malicious logo only needs to copied into the efi system partition.
That said, I’m not convinced this would affect as many systems as they say. The system would have to load boot logos from the efi system partition, which doesn’t seem very common to me.
Does FW’s firmware even support custom boot logos from the ESP? Certainly the default logo is not on the ESP, because I formatted it myself and there are no images on there
This was my original reaction as well, but was pointed to this slide in their BH presentation that suggests OEMs may load the logo in different ways, including placing them in an unsigned part of the firmware update:
(For those platforms, the attacker can presumably craft and load a firmware update to the ESP that passes Secure Boot and Intel Boot Guard verification, but contains the payload with malicious boot image data.)
Thanks @nrp for chiming in! As a security professional (CISSP and CCSP), I was curious to see what Framework and Insyde’s response would be to this. Pumped to see Insyde and Framework are on top of it.
UEFIs booting Windows and Linux devices can be hacked by malicious logo images.
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 company Binarly is currently working with Framework on their firmwares
That’s why you shouldn’t enable passwordless sudo.
ESP requires elevated privileges to write to, so you are protected in this case if keystroke injection can’t elevate privileges without authentication (assuming attacker doesn’t know your password)
Based on analysis from Binarly, we believe each of our currently launched platforms except Chromebook Edition is vulnerable to some form of LogoFAIL. We are working with our upstream UEFI supplier, Insyde, in order to get the necessary update from them to resolve this. This is occurring as part of our sustaining software initiative.
Thank you for the quick answer and openness. Other companies might be temped to delay saying that.
Everyone should remember that due to there being far fewer Framework Laptops out in the wild vs models from big brands, we should be pretty far down on a target list.
