Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack (Ars Technica) [LWN.net]

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 15:20 UTC (Thu) by domdfcoding (guest, #159754) [Link] (8 responses)

But how do you actually change the image? I looked up how to do it for my PC prior to this story breaking (because I wanted to show something different from the ROG logo) but it required modifying the UEFI update file.

Can this actually be exploited from within the OS?

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 16:22 UTC (Thu) by jafd (subscriber, #129642) [Link] (7 responses)

The original report at Binarly (https://binarly.io/posts/finding_logofail_the_dangers_of_...) says that some boards allow this by putting the custom logo into your ESP and setting an EFI variable (presumably, vendor-specific) to point to it.

They also have a table with aggregated stats: all vendors have buggy image parsers (I'd wager because there are only three firmware vendors, of which none are known for exceptional code quality) but only boards from Acer, Lenovo, and Intel are actually exploitable.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 17:47 UTC (Thu) by simon.d (guest, #168021) [Link]

Thank you very much for the information.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 23:37 UTC (Thu) by epithumia (subscriber, #23370) [Link] (5 responses)

I'm having trouble understanding how to get from "boards from three manufacturers are exploitable" to "just about every Windows and Linux device vulnerable". I thought Ars Technica aspired to be better than alarmist clickbait.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 0:04 UTC (Fri) by randomguy3 (subscriber, #71063) [Link] (2 responses)

honestly, it's a confusing article overall - for example, it seems to think that wiping or replacing your hard drive won't reset your boot partition (it's certainly possible to have such a configuration, and just reinstalling the os may well leave the boot partition alone depending on how you do it, but the article ignores any of this nuance in favour of over-reaching claims)

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 6:47 UTC (Fri) by WolfWings (subscriber, #56790) [Link] (1 responses)

If you're hit with this exploit your boot drive no longer matters. The boot drive is merely the vector for some vendors that support loading arbitrary images at boot time from the ESD.

But once it's loaded an exploit would be running in essentially the earliest of the early UEFI boot zones so it can overwrite whatever it pleases with impunity.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 10, 2023 18:04 UTC (Sun) by jacinto (subscriber, #157537) [Link]

My knowledge of EFI boot is limited to basic Linux installs on an SSD with boot and root partition. In that scheme, the EFI boot code is in the ESP boot partition (GPT type 1, FAT formatted partition). If I understand this vulnerability correctly, it would compromise the EFI boot code in the ESP by replacing the boot code file with a malicious boot code file containing a logo image that exploits the boot code’s image parser.

To my limited understanding, a compromised install could easily be erased by replacing the compromised EFI boot code file with the correct file. A reformat and reinstall of Linux on the SSD would also serve to erase any other potential malicious modifications to the system. The article seems to suggest, without nuance, that the malicious boot code becomes permanently embedded and unfixable. I could understand the permanence of the exploit if there were an embedded storage device in the motherboard that served as the EFI partition, but for the scenario I described it seems like the article’s dire claim would not be true.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 15:39 UTC (Fri) by tshow (subscriber, #6411) [Link]

> I thought Ars Technica aspired to be better than alarmist clickbait.

Look back over Dan Goodin's security articles on Ars Technica over the years and you may or may not notice a theme in this regard. Somewhere buried in any of the articles is usually some useful info, but the title and overall tone are generally BILLIONS OF MACHINES VULNERABLE TO EXPLOIT ALL IS LOST.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 9, 2023 3:20 UTC (Sat) by csamuel (✭ supporter ✭, #2624) [Link]

I think part of this is because the original article talks about boards with vulnerable parsers, but that doesn't mean that they can (currently) be exploited by uploading an image. For instance it says:

> Since the vulnerable parsers are developed and distributed by the IBVs – AMI, Insyde and Phoenix – a large percentage of devices
> UEFI firmware image out there contains a parser vulnerable to LogoFAIL. This is also confirmed by the data our platform constantly
> scans. Thanks to our triaging efforts, we were able to produce rules for fwhunt, our firmware vulnerability scanner, and confirm that
> every OEM is impacted by this supply chain problem. As we can see in the following table, we detected parsers vulnerable to
> LogoFAIL in hundreds of devices sold by Lenovo, Supermicro, MSI, HP, Acer, Dell, Fujitsu, Samsung and Intel.

But then goes on to say:

> The exploitability of these vulnerabilities relies on whether the user is able to input data to a parser. When these parsers are used to
> display a logo during boot and when this logo can be replaced by an attacker, using any of the OEM customization techniques
> described in the Attack Surface section of this blogpost, then LogoFAIL becomes an exploitable threat.

They do list 3 scenarios by which it could be exploited, with the first being the easiest (and potentially remote) attack with just 3 vendors named, but then include as the hardest using an SPI flash programmer which would require physical access & an unprotected BIOS which could expand that list considerably.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 16:47 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (5 responses)

Secure boot not really good for anything except stopping users from installing their own software on their own hardware? Who would have guessed that?

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 17:58 UTC (Thu) by jajpol (subscriber, #8044) [Link]

Victims of the Microsoft marketing department

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 21:27 UTC (Thu) by mat2 (guest, #100235) [Link] (3 responses)

Currently, false "security" arguments are frequently used to limit users' freedom (to modify their systems). For example, devices with modified Android systems (like LineageOS) are "insecure" and therefore many applications refuse to run on them. In reality, Google with DRM tools like Google Play Integrity likely tries to take a tougher grip on Android and limit any forks or free variants.

Also, Intel Boot Guard (the verification of UEFI image hash with fuses embedded into the CPU die) is done for the sake of "security", but more importantly it does prevent the user from exchanging the CPU in their laptop (which harms hardware manufacturers) or a proprietary firmware with Coreboot. For more see the Matthew Garrett's article ( https://mjg59.dreamwidth.org/58424.html ).

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 3:08 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> For example, devices with modified Android systems (like LineageOS) are "insecure" and therefore many applications refuse to run on them. In reality, Google with DRM tools like Google Play Integrity likely tries to take a tougher grip on Android and limit any forks or free variants.

I suspect it's a bit of both. If they are after the ability to, e.g., remove mail (or “expiring video” from your phone) then it's precisely the inability to run your code on your own device that they are seeking.

You may not like it, but “owner of the device may do something to his (or her) own device” is very much a security vulnerability, and that something is not limited to “make copy of movie rented for 24 hours”.

Whether it's goal worth pursuing is entirely different question, but a lot of people (and not just in government or movie industry) say the answer is “yes”.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 20:17 UTC (Fri) by mat2 (guest, #100235) [Link] (1 responses)

You may not like it, but “owner of the device may do something to his (or her) own device” is very much a security vulnerability, and that something is not limited to “make copy of movie rented for 24 hours”.

The security vulnerabilities you write about are minuscule compared to the real threats and can be further minimized with proper engineering and such. For example, attacks that target modified Android devices are rare because few people root their devices and so the criminals do not target them. Also, the LogoFAIL firmware attack is not likely to be used in the wild because it requires kernel level access in the first place, is likely complicated, device-specific and most criminals do not bother to get such persistence. I simply don't want to live in a world in which large corporations control which software we can use and which cannot.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 20:19 UTC (Fri) by mat2 (guest, #100235) [Link]

> For example, attacks that target modified Android devices are rare because few people root their devices and so the criminals do not target them.

I meant that targeting these devices does not pay off to the criminals because these devices are rare. It is similar with viruses for Linux.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 17:48 UTC (Thu) by simon.d (guest, #168021) [Link] (4 responses)

Would this attack alter a PCR (Platform Configuration Register)? Probably vendor specific?

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 19:33 UTC (Thu) by geofft (subscriber, #59789) [Link]

I think no, because you're not triggering loading anything that wouldn't already be loaded. The PCR scheme relies on the cooperation of each thing in the boot chain to hash in the next thing before passing control. The logo code is already called, and so the attacker gets code execution partway through this chain while the PCR is in a state it would have, at least briefly, legitimately been in. So the attacker can just extend the hashes and reach the same value.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 20:19 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

In theory the logo /could/ be measured (and arguably should be, probably into PCR 1), but I'm not aware of any systems that do that.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 20:39 UTC (Thu) by klossner (subscriber, #30046) [Link] (1 responses)

If the logo is part of the BIOS image (as it is on my system), it is part of the measurement into PCR 0.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 20:22 UTC (Fri) by simon.d (guest, #168021) [Link]

Thank you, good thought. Though this should protect against a changed image in the BIOS, if it is not protected by Intel Boot Guard/anything else. A changed image via the ESP would still be a successful attack, if not measured in anything else.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 18:32 UTC (Thu) by BlueLightning (subscriber, #38978) [Link] (3 responses)

A little sensational - just about every device ... but actually only the ones that use UEFI, which in the embedded space is a bit less common. Also not applicable to Android devices.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 18:47 UTC (Thu) by ballombe (subscriber, #9523) [Link] (2 responses)

Also this has nothing to do with Windows or Linux.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 21:04 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

I think "Windows and Linux" is really just a funny way of saying "not macOS." Apple doesn't let other vendors put their operating system on random hardware, and therefore they (presumably) don't even have a code path for this logo nonsense.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 3:28 UTC (Fri) by raven667 (subscriber, #5198) [Link]

What I read is that on Apple hardware the image is hardcoded as part of the signed/validated firmware as its tiny and monochrome, and they didn't bother with a facility to dynamically load it during boot. Someone also said (maybe in the article, I don't recall) that Dell includes the image in the signed part of the firmware so it's not modifiable as well, even though the loading routines are just as vulnerable as others, there's no way to get to them.

There are probably a bunch of ways to detect modified boot logo files, by changing the logo to something custom, if it gets reverted to a stock looking one, maybe something is up, or just put additional audit and AV scanning around modifying this image, AV vendors could probably get the SHA512 hash of all the extant custom images from their installed base and check for shenanigans, flagging any new hashes for further scrutiny, or blocking modification.

Im sure there is going to be a long tail of exploitable systems but it is possible to get a handle on this for new systems and maintained systems I think.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 19:55 UTC (Thu) by roc (subscriber, #30627) [Link] (11 responses)

I would like to know which, if any, of the following scenarios is true:

* UEFI vendors wrote their own codecs (why?)
* UEFI vendors chose badly implemented codecs (why?)
* UEFI vendors chose the standard well-implemented codecs (libpng, libjpeg etc) and never updated them (easy to understand why, but even ten years ago libpng etc were pretty well hardened against fuzzing attacks)
* UEFI vendors chose standard well-implemented codecs and then modified them to fit into their environment, and those modifications introduced vulnerabilities

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 21:52 UTC (Thu) by Wol (subscriber, #4433) [Link]

I think it's your third scenario. And they never updated it because that was work, and they'd have to pay someone to do it ...

Cheers,
Wol

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 3:40 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

I have no knowledge, just speculating, but I think it's #1, firmware writers not using libraries designed for applications and writing their own to fit the constraints of the environment #4, or maybe this code is older than those hardened implementations since EFI is from Itanium in the 1900s.

In any case, quality of implementation and security testing was not part of the design requirements handed to the developers, they built an image loader that loaded well formed images reliably, "job done, time to move on to the next deliverable" -- some nameless manager in the past. Their test suites are probably focused much more on initializing the hardware correctly on bootup than whether the cosmetic image loaders were robust against attack, even with all the work on SecureBoot. This is still better than the previous system which didn't have a security boundary that could be exploited, you could just change the firmware directly or modify the early boot such that the OS never can tell, there was almost no protection at all from firmware-level persistence for malware. At least this is a flaw that can be fixed.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 8:41 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> maybe this code is older than those hardened implementations since EFI is from Itanium in the 1900s.

I don't think Itanium is pre-world-war-1 :-)

Cheers,
Wol

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 21:01 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

No, but the Titanic was. It's an easy thing to confuse them after all ;) .

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 8, 2023 19:43 UTC (Fri) by roc (subscriber, #30627) [Link]

Yes, I'm sure part of the problem is failing to recognize that input to the image loading code should be treated as hostile.

Part of the dialogue around safe languages is people claiming that safe(r) languages are not needed for most code, because most code is not exposed to hostile input. This example well illustrates the weakness of that point. Determining whether code will be exposed to hostile input is not easy, especially when you have to make that decision once for all future time.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 9, 2023 0:14 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (2 responses)

I am dubious about the "pretty well hardened" position. My impression is that image codecs in the real world have fairly poor security properties and that people just don't care enough. "Fuzzing" has the problem that you're just banging harder on a known weakness area, but you may have completely overlooked real problems.

These applications should obviously use WUFFS-the-library, it's exactly perfect for them, it's C (WUFFS is not C, but WUFFS-the-library is provided as C) so they can build it with whichever 30 year old proprietary toolchain is "state of the art" in their dusty corner of reality, its performance is best-in-class and it's entirely safe.

It's very, very silly that this isn't the baseline in 2023. I believe Chrome uses WUFFS for one image format (and maybe only on Android?), and that's the sum total of real world impact. It's like if we had an effective vaccine for a serious disease and millions of people with easy access to the vaccine decided they'd rather take their chances without. Oh right, yeah, that's us.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 9, 2023 1:51 UTC (Sat) by pizza (subscriber, #46) [Link]

> It's very, very silly that this isn't the baseline in 2023.

It's probably fair to say that the UEFI bitmap parsing code hasn't been touched since it was originally written/integrated, and that that occurred at least a decade before WUFFS existed.

While WUFFS offers some advantages, it also comes with its own costs [1] and whether or not switching is "worth it" (or even feasible) has to be evaluated on a case-by-case basis.

[1] Even one-off "migration costs" can be non-trivial -- WUFFS-the-library is not a drop-in replacement for $arbitrary_parsing_library, and that's just at the API boundry. Even once that is done, will WUFFS also operate within the same code size/runtime memory/other resource constraints as the old parsing code? Finding out takes time and effort.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 11, 2023 5:18 UTC (Mon) by roc (subscriber, #30627) [Link]

I think the standard libraries for PNG and JPEG are in pretty good shape; they're used in browsers, so they've been worked over pretty hard.

I think the actual problem here might just be the BMP format. That's not much used, and is "simpler", so more people have rolled their own and gotten it wrong.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 9, 2023 7:02 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> * UEFI vendors wrote their own codecs (why?)

Pretty much all UEFI vendors base their firmware on https://www.tianocore.org/ . I tried to find where it implements image parsing, and I was not able to find it. But given that it's an unholy mess with a horrible coding style, I might have missed it.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 9, 2023 8:50 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

https://github.com/tianocore/edk2/blob/master/MdeModulePk..., but that's from 2016 so it's entirely possible that UEFI vendors are using older code

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 9, 2023 12:01 UTC (Sat) by wtarreau (subscriber, #51152) [Link]

Ouch, indeed! It looks like machine-generated code. Well, it sort of is, given that the project encourages the use of a reformater on your code. I think some projects underestimate how repellent can fantasist coding styles be against contributions and bug reports. OpenSSL learned it long ago, when trying to fix an unchecked malloc used to cause some nausea and forced you to have a break with fresh air every 3 minutes or so.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 7, 2023 21:31 UTC (Thu) by mat2 (guest, #100235) [Link] (2 responses)

Most people do not need to worry about firmware attacks anyway. Pure userland attacks are much more widespread and therefore more dangerous. Not to mention phishing.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 13, 2023 13:33 UTC (Wed) by Random167 (guest, #168499) [Link] (1 responses)

No, firmware attack is much more dangerous than OS layer attacks, because it can be hidden in your motherboard flash that cannot be deleted by an OS reinstall. It can bypass all the security measures since firmware is the earliest root of trust, and the firmware malware can pretend everything is all secure and fine to the OS, therefore it is also hard to detect.
Also the firmware update software relies on the firmware to do the job which is compromised in the first place… the worst case is to flash a new firmware by a flash programmer like dediprog, until then your system will be kept compromised.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack(ars technica)

Posted Dec 18, 2023 4:59 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I don't think that is within the scope of likelihood of this vulnerability, this isn't about modifying the firmware for persistence of an exploit after a phisihing or malware install, this is about being able to re-exploit the firmware as part of its normal boot process early enough that it's hard to detect later and can push malware persistence into the OS, which has to be built on the assumption that the tools it uses to load itself are intact. Modern firmware integrity is built by having each part having a way to validate the next part before it loads it, so the boot should always get into a known good state that makes malware hard to persist, but loading unvalidated data that can break code execution flow breaks the validation.