from the proprietary-standards-are-always-dangerous dept.
UEFI Failing: What to Know About LogoFAIL Attacks
UEFI Failing: What to Know About LogoFAIL Attacks:
- Multiple UEFI vulnerabilities can lead to Linux, Windows, and Mac exploits
- LogoFAIL persists across operating system reinstallations
- It also extends the supply chain risks to the hardware itself
Security researchers, known for their inquisitive and unconventional methods, have recently scrutinized UEFI (Unified Extensible Firmware Interface), revealing significant vulnerabilities called LogoFAIL vulnerabilities. These experts, who investigate systems to uncover unusual ways to exploit them, discovered that UEFI, the modern replacement for traditional BIOS, is susceptible to certain failures – which have wide-ranging impacts.
Specifically, researchers found that the libraries used by various system integrators and vendors in their motherboards' UEFI are vulnerable. These libraries can be manipulated to perform unforeseen operations through specially crafted images displayed during system boot-up, such as logos and banners. This manipulation effectively circumvents security features like Secure Boot, misleading the subsequent operating system.
[...] UEFI stands for Unified Extensible Firmware Interface, an advanced version of the old BIOS. It is essentially a compact operating system that manages hardware initialization and preliminary system security before transitioning control to the main operating system. UEFI oversees numerous functions, including CPU frequency, power and thermal management, memory timings, and peripheral operations. Some UEFI systems even offer network connectivity for firmware updates without an operating system being required.
Unlike BIOS, UEFI provides a consistent visual experience by displaying an image during boot-up, which remains visible throughout the UEFI initialization and into the operating system's boot phase. This differs from BIOS, which typically involves screen resolution changes and text mode resets before operating system drivers are activated.
[...] It is important to note that, despite the hype, to exploit these vulnerabilities it is necessary to have access to the system in the first place, and in that access, to have privileges to write to the EFI partition and UEFI non-volatile ram (nvram). The keen-eyed reader will realize that, if you already have that level of access, then it's not necessarily the LogoFAIL exploit itself that is the problem, but rather the persistence that it enables for other malware to abuse. Consider, for example, a ransomware that persists even system reimaging attempts after an infrastructure-wide attack. It would cripple recovery operations.
Adding insult to injury, the vulnerabilities exist across multiple platforms and architectures. It impacts both x86 and ARM-based devices. BIOS vendors like AMI, Phoenix, and others, create firmware that is affected by LogoFAIL. In turn, this makes motherboards using that firmware to also be affected by it – it doesn't matter if server-grade or consumer-grade hardware, as the same BIOS vendors will provide software for all of them. Vendors like Intel, Dell, Supermicro, Acer, and many others are therefore affected.
[...] These findings highlight another dimension of software supply chain risks. Directly targeting hardware adds to the already complex array of threats affecting software supply chains, from developer tools to source code repositories.
The fact that a given workload is potentially affected by vulnerabilities all throughout this large dependency and environment chain is something that we seem to turn a blind eye to – either through a lack of awareness or an inability to effectively prevent it – but which doesn't make it any more secure.
Just About Every Windows and Linux Device Vulnerable to New LogoFAIL Firmware Attack
UEFIs booting Windows and Linux devices can be hacked by malicious logo images:
Hundreds of Windows and Linux computer models from virtually all hardware makers are vulnerable to a new attack that executes malicious firmware early in the boot-up sequence, a feat that allows infections that are nearly impossible to detect or remove using current defense mechanisms.
The attack—dubbed LogoFAIL by the researchers who devised it—is notable for the relative ease in carrying it out, the breadth of both consumer- and enterprise-grade models that are susceptible, and the high level of control it gains over them. In many cases, LogoFAIL can be remotely executed in post-exploit situations using techniques that can't be spotted by traditional endpoint security products. And because exploits run during the earliest stages of the boot process, they are able to bypass a host of defenses, including the industry-wide Secure Boot, Intel's Secure Boot, and similar protections from other companies that are devised to prevent so-called bootkit infections.
Game over for platform security
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.
[...] 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.
Detecting LogoFAIL Vulnerabilities and Exploits at Enterprise Scale
Detecting LogoFAIL Vulnerabilities and Exploits at Enterprise Scale - Eclypsium:
IT security teams are assessing new UEFI vulnerabilities that affect Windows and Linux systems. The vulnerabilities are collectively called LogoFAIL because they exist in UEFI image parsers that display the manufacturer logo when the system boots up.
Affected vendors include UEFI suppliers AMI, Insyde, and Phoenix and device manufacturers such as Lenovo, Dell, and HP. Some vendors have already issued advisories, but we should expect the list to expand as more vendors assess their exposure.
[...] Defenders need to know which systems are affected by LogoFAIL vulnerabilities and the associated severity. The CERT Coordination Center at Carnegie Mellon has a dynamic list of affected vendors and associated security advisories.
So far, it is difficult to determine the severity as no public exploit has been published, and some of the now public vulnerabilities have been scored differently by the researchers from Binarly who discovered the LogoFAIL vulnerabilities, the UEFI firmware vendors (Phoenix Technologies, Insyde, and AMI), and the National Vulnerability Database (NVD). The severity and exploitability of each LogoFAIL vulnerability will likely depend on how affected firmware vendors and equipment manufacturers (OEMs) store and process logo images. An attacker's ability to modify these logo images or paths to them may depend on malicious software running locally on a system (with administrative or root-level privileges), by an attacker remotely accessing the system, or by an attacker who gained physical access to a target.
You should monitor and apply patches as they become available from each OEM for each product model. As of the time of this writing, the list of affected products that have associated CVE identifiers includes the following:
Insyde has issued INSYDE-SA-2023053 and assigned it a CVSS score of 4.4. The associated CVE is CVE-2023-40238 and has been scored a CVSS 5.5 (Medium) by the NVD. The aforementioned CVE correlates to Binarly's vulnerability identifier BRLY-LOGOFAIL-2023-006 with an assigned CVSS of 8.2 (High). The difference in CVSS score appears to result from differences in perceived potential impact on confidentiality, integrity, and availability.
AMI has issued AMI-SA-2023009 and assigned a score of 7.5 to each of the associated CVEs, while the NVD has assigned a score of 7.8:
- CVE-2023-39538 – AMI CVSS = 7.5 (High), NVD CVSS = 7.8 (High)
- CVE-2023-39539 – AMI CVSS = 7.5 (High), NVD CVSS = 7.8 (High)
The severity rating for the AMI vulnerabilities is higher than the CVE in Insyde firmware due to stated impact on confidentiality and integrity.
(Score: 1, Informative) by Anonymous Coward on Friday December 29, @05:32AM (4 children)
OMG! If someone has pwned my computer so hard that they can change my boot up logo, they can pwn my computer!
By the way, I thought Dell etc use Boot Guard to prevent the logo from being changed? Or is this a different/updated exploit that breaks/bypasses such protections?
https://www.zdnet.com/article/this-is-how-to-protect-your-computers-from-logofail-attacks/ [zdnet.com]
From the actual group exploiting it:
https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/ [binarly.io]
Other vendors (OEM etc) don't protect the logos presumably so you can use your own logos.
(Score: 2) by DannyB on Friday December 29, @04:43PM (2 children)
Why should it ever be necessary to change the boot logo from that of the manufacturer?
Oh, so a corporation can make their own corporate logo appear when computers boot up. Because that is sooper important.
Next up: boot up corporate logos need to support animated GIFS.
Later on: boot up corporate logos need to support 1080p video animations.
With a side of joystick controller support while you wait for Windoze to eventually display a startup screen . . . snooze.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by looorg on Friday December 29, @05:15PM
Considering that a lot of companies (and other entities) appear to spend an awful lot of time to create a corporate identity and a graphical profile I'm sure they would if they could and it was easy. After all several places I worked at had an official desktop background, that was locked. You couldn't mess to much with the desktop at all. That was locked down. I guess they don't want you to move or change things for support reasons.
(Score: 2) by cereal_burpist on Saturday December 30, @04:02AM
Later on, part II: "I asked IT to re-image my laptop, and they Rickrolled my BIOS! Those bastards!"
(Score: 2) by mcgrew on Saturday December 30, @12:37AM
I think the whole purpose of these hacks is to let you, the system owner, bypass the manufacturer's bullshit.
mcgrewbooks.com mcgrew.info nooze.org
(Score: 4, Insightful) by Mojibake Tengu on Friday December 29, @06:42AM (8 children)
Dear funny software engineers,
When Artificial Intellects come who understand assembly and their own machine code on critical platforms, you are done. Completely.
No precious programming languages will be relevant anymore. No useless users will be relevant anymore. Do you understand?
All formerly made well-paid secret backdoors will belong to them. Nor EFI joke nor serious kernels be an exception.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 4, Touché) by Opportunist on Friday December 29, @10:49AM
AI can't even do first grader math properly. I think we're safe for the time being.
(Score: 2) by DannyB on Friday December 29, @04:52PM (6 children)
I have privately (until now) wondered if ML (not AI but Machine Learning, a subset of AI on the Venn diagram) will eventually be the death of current cryptography.
Algorithms are designed to be resistant to (1) brute force attacks and (2) cryptanalysis. Item 1 means using bigger and beefier computers to try chosen plaintext attacks, or other attacks.
Item 2 might be vulnerable to a sufficiently sophisticated ML that figures out how to break the algorithm through analysis rather than brute force. Like solving a puzzle. Just a sophisticated puzzle that is not easily solved by slow, inefficient, annoying, noisy, smelly humans.
Extending that paranoia, it really is just more puzzle solving to look at code and analyze for vulnerabilities.
If only the world had not been built on programming languages that think bytes and characters are the same thing (but Zig seems to continue this trend?) and has strcopy functions that have no length bounds checking but rather depending on null terminated strings. Oh my, oh my. Lord help us.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by istartedi on Saturday December 30, @01:00AM (5 children)
Seriously? Zig uses nul-term? I thought it was a relatively recent language. Kind of funny that in this day of 64-bit words that can hold an entire DOS file name (sans extension) we'd still be using such a fragile hack, which was designed to save memory. Memory was that expensive. Now you could just put a 32-bit pointer and a length field in to one 64-bit word, and it'd be fine for 99.9% of what you do with strings, and passed around at lightning speed, or even use full 64-bit pointers and length fields with a memcpy, it'd probably have no noticeable impact on anything--most optimization is premature anyway, and nul-term is risky optimization built right in to the language. It was forgivable 50 years ago, but surely not 10 or even 20 years ago, and I don't think Zig is that old.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by DannyB on Tuesday January 02, @12:57AM (4 children)
I was referring to Zig examples where strings are arrays of 8-bit bytes. Bytes are a different thing than a character. (in the 21st century)
Characters are unicode, heck, I could post emojies right here in this message. I can use unicode characters in Java source code.
Bytes are 8 bits wide.
We all seem to recognize that integers are different than strings. And good languages require use of functions to convert between integers and strings. Similarly functions should be required to convert between bytes and strings. And those functions are called a "Charset", like in Java and C#. A character can be one or more bytes.
Welcome to the 21st century.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by istartedi on Thursday January 04, @01:07AM (3 children)
Point taken, but nul-term is silly whether you're restricting yourself to the ASCII code point or not; and that was the primary thrust of what I was saying.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by DannyB on Thursday January 04, @03:29PM (2 children)
I completely agree that null terminated strings were and are a bad idea.
However characters vs bytes highlights the insanity of null termination.
Now you can have null terminated arrays of bytes. Which means arrays of bytes can't contain zeros.
And you could have a null terminated array of characters, however the complicates decoding bytes into characters. If a multi-byte character, say a four byte sequence making up an emoji character for Pitok well known to the Klingon species, contains a zero byte, that zero is part of a character, not a termination of the string.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by istartedi on Thursday January 04, @06:58PM (1 child)
I'm not familiar with all the Unicode implementations. I was given to understand however that most of them expand in to 16-bit or 32-bit strings in memory so at least that kind of insanity doesn't occur. I believe that UTF-8 was deliberately designed so that none of the encodings would have a zero-byte, specifically so that C's NUL-term'd strings would still work if you maintained UTF-8 encoding in memory. ie, Unicode carries C's baggage!
I'd have to do a little googling to confirm that though, I've literally got places to go...
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by DannyB on Thursday January 04, @10:27PM
Java formalizes it very well.
There an object type called a Charset. You can introduce new Charsets.
A Charset provides bi directional translation between bytes and characters in a uniform way.
Characters are a single type that represent Unicode characters.
One Java Charset (for traditional reasons) is US_ASCII. Another is UTF-8. Any minimally conforming implementation is required to have built in support for both US_ASCII and UTF-8.
An InputStream and OutputStream are used for reading and writing bytes (not characters). There are Buffered versions available (BufferedInputStream and BufferedOutputStream) which can wrap any other InputStream or OutputStream.
A Reader is an input for Characters. There is a subclass called InputStreamReader, which is a Reader which gets its bytes from an InputStream. However you can build your own Reader subclasses that produce characters from other sources. Similarly there is a Writer with similar subclasses like OutputStreamWriter.
Reader / Writer deal with characters.
Input / Output deal with bytes.
A Charset is used by both an InputStreamReader and an OutputStreamWriter in order to translate between the two different data types (Character vs byte)
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 4, Funny) by darkfeline on Friday December 29, @07:36AM (1 child)
For those of you who hate Secure Boot, now you have a way to circumvent it, until it gets patches.
Join the SDF Public Access UNIX System today!
(Score: 2) by DannyB on Thursday January 04, @10:30PM
Until the patches can be circumvented and need patches for the patches on top of other patches for patches.
Soon it's patches all the way down.
See how Apache web server got its name. (hint: a patchy web server)
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 4, Interesting) by Opportunist on Friday December 29, @10:57AM (1 child)
Remember the good ol' days where doing a BIOS upgrade was a real task? You had to open the crate, find the relevant jumper to physically move from one pin to another, boot up the boot disk (for the kids: That was a physical 3.5 or 5.25 inch large plastic thing that we had to put into a slot at the front of the computer, kinda like some large USB dongle but it went all the way into the computer... watch some "floppy music" videos if you want to see what they looked like) and THEN you finally could upgrade your BIOS. And hope and pray you don't brick your PC in the process.
Now, that's far more convenient and easy today. But that process up there is nearly impossible to abuse. Barring a social engineering or a supply level attack where an attacker can hijack the webpage of the board manufacturer long enough to get a relevant number of users to upgrade (bloody unlikely, since nobody upgraded their BIOS back then unless it was a showstopper not to, i.e. you wanted to use something the old BIOS didn't support, which in turn meant that you could only get a tiny fraction of the users, and only of THIS particular mainboard), this was pretty much no relevant attack vector.
Well, now it is.
(Score: 4, Informative) by looorg on Friday December 29, @03:50PM
Remember when the boot actually showed useful system information instead of a corporate logotype and some "loading bar"? When you could see the memory, cpu, disk sizes etc. Those were the happy dayz ...
Upgrading bios was always a bit scary in some regard, very early on if the process failed for some reason (read error on the floppy etc) that was not good.
(Score: 3, Interesting) by bzipitidoo on Friday December 29, @02:08PM (3 children)
I have always had the impression that the peddlers of UEFI don't put user security at the top of their priorities. Sometimes it seems the top priority is to give commercial software an unfair advantage over libre software.
Often, a consequence of such priorities is embarrassingly feeble security. Frankly, it's bull that they didn't even bother to vet the library software they threw into UEFI. Nope, soon as UEFI met their priorities, they were done, and the heck with real security. Even pretty splash screen logos have higher priority! Because, looks! Appearances! How typical of commercial products.
(Score: 2) by Joe Desertrat on Sunday December 31, @12:58AM
Just wait until Total Platform Management takes over...
(Score: 2) by DannyB on Thursday January 04, @10:33PM (1 child)
Hey now, your security is our Number 1 priority !
Priorities:
0. profit
1. security
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 2) by bzipitidoo on Friday January 05, @03:06AM
Ascribing programmers' counting style to non-programmers? The horror!
Or, the programmers are in charge? Scary!
(Score: 3, Insightful) by Runaway1956 on Friday December 29, @02:50PM (1 child)
Funny that the eye candy is held out as if it a real feature. I'll note that the messages that flash past during a BIOS bootup are informative (depending on the board of course). The UEFI screen? Tells you nothing really. That suits Joe Average, because he doesn't know, doesn't care, what's happening behind the facade.
Much the same with the OS boot sequence. I actually like seeing the messages scroll down the screen. Rare ocassion when the messages halt, you can see where the system hung up, without even checking any logs. I mean, seriously, video driver failed to load is pretty obvious, right? And, X11 has never had any kind of a backup plan to use the old driver, or anything like that, driver fails, desktop fails, end of story. Log into CLI and fix the issue.
Feed me information during bootup - if I get tired of looking at it, I'll go pour a coffee, and come back when bootup finishes.
(Score: 2) by Joe Desertrat on Sunday December 31, @01:11AM
Indeed. Apparently seeing the messages scroll down the screen "frightened" some users, so they eliminated it. I used to manually change it to show the messages again, but I got tired of doing that and I don't know if you still can. It seems that Linux continually trickles towards doing things the Microsoft or Apple way, where as much of the O/S and its processes are hidden from users lest they get ideas...
(Score: 0) by Anonymous Coward on Saturday December 30, @12:49AM
Agencies love back doors. This is one got caught. The ones we don't know about are where the real genius is.