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.
Sayeth Bruce Schneier:
Today’s top-secret National Security Agency programs become tomorrow’s Ph.D. theses and the next day’s hacker’s tools.
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)
will there be a BIOS update to patch it?
I just submitted a report request, I’ll respond once I receive something.
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
We’re currently discussing this with Binarly (who discovered and disclosed LogoFAIL) to determine whether our current UEFI firmware is vulnerable.
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:
(From the slides here.)
(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.
Interested read from Ars Technica
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
Yep, I also want to know if a changed image would result in a different TPM2 state and which PCR would differ.
I guess this attack would also be an attack vector for loading a logo that could compromise a machine.
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.
This is great to hear. Thanks @nrp. It will be a really good example to show how FW has strengthened the BIOS maintenance approach.
Figured as much. Thanks for acknowledging. My research with Recorded Future’s threat intel platform suggests this is already beginning to be exploited in the wild with bad logos being implemented. Glad to see Framework and Insyde are on it and keeping our computers safe.
@nrp Can you please provide some insights here? I guess the original logo is measured into PCR0, so this could detect an attack (since the framework logo is not protected by intel boot guard). Would a changed image via the ESP change e.g. PCR1?
@nrp: Is there a way to skip the image parsing process? Let’s say I press F2 at boot to enter the BIOS, is a custom logo not parsed? If so, if I then continue to boot, do I skip an attack?
Especially if it will take longer to release BIOS updates, please investigate some possible “mitigations”.