logoFail

[The Muffin Man]

No, I don't think the sky is falling, but it did make for an interesting read.
https://arstechnica.com/security/2023/1 ... re-attack/

[t42]

Predictable, isn't it? Starting from the first boot-time logo I encountered many years ago, I'm switching it off in the BIOS first thing.

[MurphCID]

So how do we mitigate this thing?

[t42]

So how do we mitigate this thing?

Perpetrator does need the password just physical access to equipment. Some strongbox, safe or strongroom will do.

[The Muffin Man]

So how do we mitigate this thing?

I have no idea. I think the BIOS creators are "fixing" things. But what about all the old hardware/BIOSes that are EOL?

[MurphCID]

So how do we mitigate this thing?

I have no idea. I think the BIOS creators are "fixing" things. But what about all the old hardware/BIOSes that are EOL?

That is what worries me on my X370 Ryzen desktop system. Also how do you update firmware in Linux?

[GreenIsBest]

*sigh*
Yet ANOTHER incident, where the pointless addition of unecessary features and capabilities for no other reason than it-looks-cool and hubris, ends up causing more trouble than they are worth. And on the most critical and priviledged layer of computing no less.

Seriously, genuine curiosity, what is the point of a BIOS/UEFI firmware having image parsing code? Why do you need logos on the firmware, it's not like they "prove" anything as far as trust/warranty goes in the supply chain; case in point, this logofail proves that point and then some.
A simple "Version nº xxxxxxx Copyright <manufacturer> year-date" text box plastered on the BIOS/UEFI screen provides all the needed confirmation about who programed the firmware or manufactured the board.

It even falls flat & redundant as brand awarness, as it's not like the logo isn't already carved or stickered 2-3 times on the device's casing and hardware. As for those cases where the firmware maker isn't the device manufacturer, it's not like most people even know what firmware is, let alone know that they came from different makers; kinda lost a oportunity to save money/work by catering things to the lowest common denominator.

Logo's were already unecessary back in the BIOS days (looking at you EnergyStar and AmericanMegatrends), and they certainly aren't any better now; but at least back then they were just ASCII art, so they were part of the very necessary code that allowed text/characters parsing to allow you to even interact with the BIOS in the first place.

Ok, I'm calm now.

[MurphCID]

System 76 just let me know they are not, repeat not, vulnerable to this malware. That is a good thing.

[The Muffin Man]

System 76 just let me know they are not, repeat not, vulnerable to this malware. That is a good thing.

That is waaaay cool.

[t42]

Though linked article title goes "every Windows and Linux device vulnerable to new LogoFAIL firmware attack" it is not exactly new. It is just a particular instance of vulnerable library which uses mechanism introduced by Apple in XX century and addressing the need of updating the code in case of new hardware, putting a device I/O driver in the computer memory map. The problem is that the code stays in the memory after boot up. Later this idea migrated to IBM PC systems and expanded to the point of no return. UEFI is specifically vulnerable on its third stage of boot procedure (DXE) when necessary drivers absent in static code are loaded and devices I/O is set, disks are mounted and OS boot code is executed. All that code, vulnerable or not, stay resident in memory after OS takes control. There were many incidents in the past exploiting this mechanism, including manufacturer itself, see Lenovo security and privacy incidents, or Discovery of new UEFI rootkit exposes an ugly truth - The attacks are invisible to us.
Probably the exploit code should be designed for Windows or Linux kernel specifically. Also such attack in its modern form is void for legacy BIOS boot. And most importantly, to benefit of the exploit you should find a competent person who could load malicious code into your laptop or that person should obtain your laptop for some reasonable time. Also never update BIOS firmware from untrusted source.

[MurphCID]

Agreed, I was not clear from the article how the malware was deployed in RL. If someone has to have access to your computer then that is an issue of personal security.

[The Muffin Man]

I think the moral of the story is that you can't check your brain at the door when you install stuff and click click click done. Always trust your source and always read prompts.
https://www.youtube.com/watch?v=uZBu4mtALFo

[MurphCID]

Any updates on this exploit and how it is deployed?

[mediclaser]

Can this thing infect a bootable USB drive (e.g. Linux Mint installer)?
Is there a way to make a bootable USB drive to detect and remove this type of malware?
This would make me hesitate to buy a used laptop.

[t42]

Can this thing infect a bootable USB drive (e.g. Linux Mint installer)?
Is there a way to make a bootable USB drive to detect and remove this type of malware?

You are using signed installation ISO. It is up to you to safeguard your property from tampering with.
To get that specific rootkit you need to find malicious firmware somewhere and use it for updating the computer. Rootkit should be designed specifically for your device and targeted specific OS, presumably Windows. This type vulnerability is known from 1972 and was demonstrated in 1988, and how many Linux computers where infected in the wild this way since then? -- allegedly, one.
Note that some vendors, such as Dell, have models with logo hardcoded, so they are not vulnerable to logoFail. Also many BIOSes have option to switch logo off, it is a way to protect itself and I customarily disabling it for years on all my systems.

[sylvain1_]

No, I don't think the sky is falling, but it did make for an interesting read.
https://arstechnica.com/security/2023/1 ... re-attack/

the sky is falling, plz help