354
submitted 11 months ago by Chewy7324@discuss.tchncs.de to c/linux@lemmy.ml
top 50 comments
sorted by: hot top controversial new old
[-] _edge@discuss.tchncs.de 162 points 11 months ago

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.

In short, the adversary requires elevated access to replace a file on the EFI partition. In this case, you should consider the machine compromised with or without this flaw.

You weren't hoping that Secure Boot saves your ass, were you?

[-] deadcade@lemmy.deadca.de 45 points 11 months ago

Since the EFI partition is unencrypted, physical access would do the trick here too, even with every firmware/software security measure.

[-] _edge@discuss.tchncs.de 23 points 11 months ago

True, but this was the case without this finding, wasn't it? With write access to the EFI you could replace the boot loader and do whatever you please.

load more comments (1 replies)
[-] plinky@hexbear.net 18 points 11 months ago

The worst part it persists through reinstalls (if i understood correctly)

[-] _edge@discuss.tchncs.de 11 points 11 months ago

This is also my understanding, at least of you keep the EFI partition.

[-] Bitrot@lemmy.sdf.org 24 points 11 months ago* (last edited 11 months ago)

It can outlast those too.

In many of these cases, however, it’s still possible to run a software tool freely available from the IBV or device vendor website that reflashes the firmware from the OS. To pass security checks, the tool installs the same cryptographically signed UEFI firmware already in use, with only the logo image, which doesn’t require a valid digital signature, changed.

[-] Bipta@kbin.social 10 points 11 months ago
[-] Bitrot@lemmy.sdf.org 12 points 11 months ago

It's reminiscent of boot sector viruses in the DOS days.

[-] blindsight@beehaw.org 18 points 11 months ago* (last edited 11 months ago)

The idea is also that a compromised system will remains compromised after all storage drives are removed.

load more comments (1 replies)
[-] InnerScientist@lemmy.world 15 points 11 months ago

replace a file on the EFI partition.

Doesn't this mean that secure boot would save your ass? If you verify that the boot files are signed (secure boot) then you can't boot these modified files or am I missing something?

[-] _edge@discuss.tchncs.de 14 points 11 months ago

Well, not an expert. We learned now that logos are not signed. I'm not sure the boot menu config file is not either. So on a typical linux setup you can inject a command there.

load more comments (5 replies)
[-] Ithorian@hexbear.net 11 points 11 months ago

So if I have my computer set that it needs a sudo password for most changes am I good?

[-] _edge@discuss.tchncs.de 14 points 11 months ago

Yes, that's my understanding. A normal user cannot do this. (And of course, an attacker shouldn't not control a local user in the first place.)

Physical access is also a risk, but physical access trumps everything.

[-] Ithorian@hexbear.net 11 points 11 months ago

Thanks for the answer. Unless my dog learns how to code I think I'm safe from anyone getting physical access

[-] PhatInferno@midwest.social 13 points 11 months ago

As a hacker imma start teaching dogs to code as part of my breakin process, sorry bud

load more comments (2 replies)
load more comments (1 replies)
load more comments (3 replies)
[-] Yewb@kbin.social 75 points 11 months ago

Fyi if someone had physical access / administration access due to another vulnerability to your machine they can exploit it, news at 11:00

load more comments (6 replies)
[-] JakenVeina@lemm.ee 66 points 11 months ago* (last edited 11 months ago)

Did anyone really think that making UEFI systems the equivalent of a mini OS was a good idea? Or having them be accessible to the proper OS? Was there really no pushback, when UEFI was being standardized, to say "images that an OS can write to are not critical to initializing hardware functionality, don't include that"? Was that question not asked for every single piece of functionality in the standard?

[-] gerdesj@lemmy.ml 53 points 11 months ago

Did anyone really think that making UEFI systems the equivalent of a mini OS was a good idea

UEFI and Secure Boot were pushed forcibly by MS. That's why FAT32 is the ESP filesystem.

If I had to guess, a brief was drafted at MS to improve on BIOS, which is pretty shit, it has to be said. It was probably engineering led and not an embrace, extinguish thing. A budget and dev team and a crack team of lawyers would have been whistled up and given a couple of years to deliver. The other usual suspects (Intel and co) would be strong armed in to take whatever was produced and off we trot. No doubt the best and brightest would have been employed but they only had a couple of years and they were only a few people.

UEFI and its flaws are testament to the sheer arrogance of a huge company that thinks it can put a man on the moon with a Clapham omnibus style budget and approach. Management identify a snag and say "fiat" (let it be). Well it was and is and it has a few problems.

The fundamental problem with UEFI is it was largely designed by one team. The wikipedia page: https://en.wikipedia.org/wiki/UEFI is hilarious in describing it as open. Yes it is open ... per se ... provided you decide that FAT32 (patent encumbered) is a suitable file system for the foundations of an open standard.

I love open, me.

[-] evranch@lemmy.ca 26 points 11 months ago

UEFI is flawed for sure, but there's no way that any remaining patents on FAT32 haven't expired by now.

[-] OmnipotentEntity@beehaw.org 13 points 11 months ago* (last edited 11 months ago)

You may be surprised to learn that they didn't all run out until 2013. UEFI had been around for 7 years by this time, and Microsoft was doing patent enforcement actions against Tom Tom during this time period.

Sure, they're expired now, but not at the time. It was supposed to be an open standard at the time.

load more comments (1 replies)
[-] interceder270@lemmy.world 15 points 11 months ago

Less is more. I feel we've forgotten that so worthless designers can justify their useless existences.

load more comments (1 replies)
[-] HiddenLayer5@lemmy.ml 12 points 11 months ago* (last edited 11 months ago)

It breaks the cardinal rule of executing privileged code: Only code that absolutely needs to be privilaged should be privileged.

If they really wanted to have their logo in the boot screen, why can't they just provide the image to the OS and request through some API that they display it? The UEFI and OS do a ton of back and fourth communication at boot so why can't this be apart of that? (It's not because then the OS and by extension the user can much more easily refuse to display what is essentially an ad for the hardware vendor right? They'd never put "features" in privileged code just to stop the user from doing anything about it... right?)

load more comments (1 replies)
[-] HiddenLayer5@lemmy.ml 46 points 11 months ago* (last edited 11 months ago)

I've never been a fan of the UEFI logo inserting itself into the boot screen. It's basically just an advertisement for the hardware vendor because they're jealous of the OS having the spotlight. And it's an ad that, like so many other ads before it, screws over the security and privacy of the advertisee because fuck you that's why.

[-] ddkman@lemm.ee 15 points 11 months ago

I don't know. It looks more aesthetically consistent. Your computer has to display something. Average users would be scared if it dumped logs on the display. so the vendor logo makes sense. It COULD just say loading, but this is a bit pedantic I think.

[-] nik282000@lemmy.ca 10 points 11 months ago

When it comes to security, particularly at boot time, fuck the user. Users don't interact with devices at boot time so it doesn't matter if it shows a blank screen, a mile of logs or a screaming clown penis. If it was up to users no device or service would have a password or security of any kind, and every byte of information about your life would be owned by 'The Cloud." Let the marketing wanks insert their logo into the Windows boot process,

load more comments (3 replies)
load more comments (1 replies)
[-] ShittyBeatlesFCPres@lemmy.world 38 points 11 months ago

I can’t believe stupid, pointless marketing crap didn’t have the best of the best working to ensure security.

[-] charonn0@startrek.website 31 points 11 months ago

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.

So, does disabling the boot logo prevent the attack, or would it only make the attack obvious?

[-] lazylion_ca@lemmy.ca 15 points 11 months ago

If you have access to replace the logo file, you probably have access to enable it as well.

load more comments (1 replies)
[-] redcalcium@lemmy.institute 31 points 11 months ago

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.

Me using an old PC with BIOS instead of UEFI: 😏

[-] ryannathans@aussie.zone 45 points 11 months ago

Also known as using a pc with unpatched cpu vulnerabilities

[-] kugmo@sh.itjust.works 13 points 11 months ago

gigachads use mitigations=off anyways

load more comments (1 replies)
[-] planish@sh.itjust.works 21 points 11 months ago

Hello I am writing the firmware for MotherBoard 2021, a definitely completely different product than MotherBoard 2020, I am going to ship in in 2 weeks for Christmas, and I am going to write an image decoder on top of bare metal, and it is "not" going to let you hack the pants off the computer.

Said no one ever.

[-] palordrolap@kbin.social 20 points 11 months ago

It's rare that I get to feel anything remotely comforting about not being able to afford new hardware, but if I understand correctly, my BIOS-only dinosaur can't be exploited.

Still vulnerable to thousands of other exploits no doubt, but not this one.

load more comments (1 replies)
[-] HiddenLayer5@lemmy.ml 20 points 11 months ago* (last edited 11 months ago)

The article didn't mention this, but would disabling the UEFI logo in the boot screen mitigate the vulnerability until proper patches get rolled out? (Or honestly at this point, I'd keep it disabled even after it's patched in case they didn't patch it right. UEFI's are all proprietary so it's not like you can check.) Since the vulnerability is in the image parser, would bypassing that be enough?

Do they even let you disable it?

load more comments (1 replies)
[-] const_void@lemmy.ml 16 points 11 months ago

We need more machines that support coreboot. These proprietary firmware vendors have been getting rich off making our machines worse for too long.

load more comments (2 replies)
[-] kugmo@sh.itjust.works 15 points 11 months ago

So this is only for the background of the motherboard boot up logo like from Asus, Acer, Gigabyte ect? Not your grub or rEFInd background correct?

[-] elscallr@lemmy.world 10 points 11 months ago
[-] TheCaconym@hexbear.net 13 points 11 months ago

BIOS booting stays winning

[-] 0x0@programming.dev 13 points 11 months ago

I wonder if old BIOS are vulnerable...

[-] admin@lemmy.my-box.dev 20 points 11 months ago

Nope, they aren't as universal as EFI. I think the closest comparable attack vector for "old tech" is a bootsector virus.

[-] LainOfTheWired@lemy.lol 12 points 11 months ago

I wonder if this effects coreboot builds like heads as they allow you to use external devices like a nitrokey for verification when you boot

[-] milicent_bystandr@lemm.ee 11 points 11 months ago

So, does this affect dual boot systems, if e.g. Windows is compromised, now that malware in the efi partition can compromise the Linux system next time it boots? Yikes!

I suppose in principle malware from one OS can attack the other anyway, even if the other is fully encrypted and/or the first OS doesn't have drivers for the second's filesystems: because malware can install said drivers and attack at least the bootloader - though that night have been protected by secure boot if it weren't for this new exploit?

[-] elscallr@lemmy.world 11 points 11 months ago

It would effect any UEFI based system regardless of OS from one of the affected manufacturers (which is basically all of them).

load more comments (2 replies)
load more comments (2 replies)
load more comments
view more: next ›
this post was submitted on 06 Dec 2023
354 points (96.3% liked)

Linux

48376 readers
1750 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS