autotldr@lemmings.world
on 06 Dec 2023 17:05
nextcollapse
This is the best summary I could come up with:
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.
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 participating companies comprise nearly the entirety of the x64 and ARM CPU ecosystem, starting with UEFI suppliers AMI, Insyde, and Phoenix (sometimes still called IBVs or independent BIOS vendors); device manufacturers such as Lenovo, Dell, and HP; and the makers of the CPUs that go inside the devices, usually Intel, AMD or designers of ARM CPUs.
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.
LogoFAIL is a newly discovered set of high-impact security vulnerabilities affecting different image parsing libraries used in the system firmware by various vendors during the device boot process.
The original article contains 663 words, the summary contains 232 words. Saved 65%. I’m a bot and I’m open source!
_edge@discuss.tchncs.de
on 06 Dec 2023 17:11
nextcollapse
Summary does not contain the actual vulnerability or exploit.
amju_wolf@pawb.social
on 06 Dec 2023 17:35
collapse
Because there really isn’t one, lol.
By the time an attacker has a write access to your boot permission everything else is kinda fucked already.
Bitrot@lemmy.sdf.org
on 06 Dec 2023 17:45
nextcollapse
This is worse than many, since it persists across reinstalls and even potentially drive swaps, and fools systems such as secure boot.
wmassingham@lemmy.world
on 06 Dec 2023 20:35
collapse
If it’s only on the ESP, it won’t persist across reinstalls, and definitely not drive swaps.
But I do see mentions of attacking via firmware capsule. If that works, then yes, that will persist.
Bitrot@lemmy.sdf.org
on 06 Dec 2023 21:13
collapse
ESP is usually not cleared on a reinstall unless somebody takes the extra step to do so. Since each OS has its own directory within the ESP their installers don’t push it. I was mostly referring to modification in firmware though.
Chewy7324@discuss.tchncs.de
on 06 Dec 2023 17:49
collapse
Yes, an attacker with write access to boot already compromised the entire OS and data. Usually replacing the storage or reinstalling the OS would get rid of the attacker. But this exploit happens early in the boot process, before the OS even loads.
This means the only way to ensure a network remains uncompromised after an attack is physically destroying any infected devices or replacing their mainboard.
There are major benefits to this approach. One is that no executable code ever touches the hard drive, a technique known as fileless malware that hampers detection by antivirus and other types of endpoint protection software. Another benefit: Once the image is in place, it ensures a device remains infected even when an operating system is reinstalled or the main hard drive is replaced.
spader312@lemmy.world
on 07 Dec 2023 17:57
collapse
Good bot
plinky@hexbear.net
on 06 Dec 2023 17:09
nextcollapse
damn 😱
redd@discuss.tchncs.de
on 06 Dec 2023 21:49
collapse
Don’t panic!
_edge@discuss.tchncs.de
on 06 Dec 2023 17:17
nextcollapse
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?
plinky@hexbear.net
on 06 Dec 2023 17:20
nextcollapse
The worst part it persists through reinstalls (if i understood correctly)
_edge@discuss.tchncs.de
on 06 Dec 2023 17:22
collapse
This is also my understanding, at least of you keep the EFI partition.
Bitrot@lemmy.sdf.org
on 06 Dec 2023 17:44
collapse
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.
Bitrot@lemmy.sdf.org
on 06 Dec 2023 18:06
collapse
It’s reminiscent of boot sector viruses in the DOS days.
deadcade@lemmy.deadca.de
on 06 Dec 2023 17:59
nextcollapse
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
on 06 Dec 2023 20:40
collapse
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.
deadcade@lemmy.deadca.de
on 07 Dec 2023 08:15
collapse
Unless a proper secure boot + FDE setup is in place.
timicin@lemmygrad.ml
on 06 Dec 2023 18:49
nextcollapse
You weren’t hoping that Secure Boot saves your ass, were you?
i wonder if containerized firefox (eg snap/flatpak) will
Ithorian@hexbear.net
on 06 Dec 2023 19:52
nextcollapse
So if I have my computer set that it needs a sudo password for most changes am I good?
_edge@discuss.tchncs.de
on 06 Dec 2023 20:38
nextcollapse
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
on 06 Dec 2023 20:55
collapse
Thanks for the answer. Unless my dog learns how to code I think I’m safe from anyone getting physical access
PhatInferno@midwest.social
on 06 Dec 2023 22:09
collapse
As a hacker imma start teaching dogs to code as part of my breakin process, sorry bud
FigMcLargeHuge@sh.itjust.works
on 07 Dec 2023 02:55
nextcollapse
Introduce him or her to FidoNet.
Murdoc@sh.itjust.works
on 07 Dec 2023 03:28
collapse
Ah, so the next Air Bud movie will be what, Hack Bud?
“There’s nothing in the specifications that says that a dog can’t have admin access.”
“Nothing but 'net!”
Unless they find another way to escalate privileges… A bug, a random binary with suid, etc
InnerScientist@lemmy.world
on 06 Dec 2023 21:06
nextcollapse
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
on 06 Dec 2023 22:23
nextcollapse
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.
If it can execute in ram (as far as I understand, they’ve been talking about fileless attacks, so… Possible?), it can just inject whatever
Addit: also, sucure boot on most systems, well, sucks, unless you remove m$ keys and flash yours, at least. The thing is, they signed shim and whatever was the alternative chainable bootloader (mako or smth?) effectively rendering the whole thing useless; also there was a grub binary distributed as part of some kaspersky’s livecd-s with unlocked config, so, yet again, load whatever tf you want
InnerScientist@lemmy.world
on 07 Dec 2023 11:19
collapse
Last time I enabled secure boot it was with a unified kernel image, there was nothing on the EFI partition that was unsigned.
Idk about the default shim setup but using dracut with uki, rolled keys and luks it’d be secure.
After this you’re protected from offline attacks only though, unless you sign the UKI on a different device any program with root could still sign the modified images itself but no one could do an Evil Maid Attack or similar.
The point with m$ keys was that you should delete them as they’re used to sign stuff that loads literally anything given your maid is insistent enough.
[note: it was mentioned in the arch wiki that sometimes removing m$ keys bricks some (which exactly wasn’t mentioned) devices]
Yeah, if someone has write access to your boot partition then you're kind of already screwed.
0x0@programming.dev
on 06 Dec 2023 17:25
nextcollapse
I wonder if old BIOS are vulnerable…
admin@lemmy.my-box.dev
on 06 Dec 2023 17:48
collapse
Nope, they aren’t as universal as EFI. I think the closest comparable attack vector for “old tech” is a bootsector virus.
charonn0@startrek.website
on 06 Dec 2023 17:29
nextcollapse
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?
Not necessarily, I guess. They’re talking about a firmware upgrade of sorts, and, at least on the machines I own(ed), performing it didn’t reset user settings (which disabling the logo is)
ShittyBeatlesFCPres@lemmy.world
on 06 Dec 2023 17:52
nextcollapse
I can’t believe stupid, pointless marketing crap didn’t have the best of the best working to ensure security.
Yewb@kbin.social
on 06 Dec 2023 17:56
nextcollapse
Fyi if someone had physical access / administration access due to another vulnerability to your machine they can exploit it, news at 11:00
sadreality@kbin.social
on 06 Dec 2023 18:00
collapse
More like reflashing entirely or just changing the image. Alternatively, you can often disable showing the.logo somewhere in the settings.
What’s known as resetting bios is more like removing the stuff saved in CMOS, AFAIK
Nyfure@kbin.social
on 07 Dec 2023 07:17
nextcollapse
Most fastboot options dont show the logo until windows bootloader comes along.
Though i am not sure how or why the logo is displayed when windows loads? Is that the same image? Loaded and displayed again or just didnt clear the display?
I think so, but there can probably be some vendor-specific differences, like storing the image in a place that doesn’t get overwritten. For example, thinkpads provide a way to supply your own image, and when installing updates after that you’re asked if you want to keep it. But yeah, the update should neuter it anyways
TheCaconym@hexbear.net
on 06 Dec 2023 18:04
nextcollapse
BIOS booting stays winning
redcalcium@lemmy.institute
on 06 Dec 2023 19:44
nextcollapse
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
on 06 Dec 2023 22:31
collapse
Also known as using a pc with unpatched cpu vulnerabilities
kugmo@sh.itjust.works
on 07 Dec 2023 06:18
collapse
gigachads use mitigations=off anyways
ryannathans@aussie.zone
on 07 Dec 2023 09:08
collapse
Makes it go fast
palordrolap@kbin.social
on 06 Dec 2023 20:26
nextcollapse
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.
Is this potentially useful to me? Since it is persistent, can I use it on this motherboard I have over here that insists on using UEFI even if I do not want to?
milicent_bystandr@lemm.ee
on 06 Dec 2023 22:09
nextcollapse
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
on 06 Dec 2023 23:57
nextcollapse
It would effect any UEFI based system regardless of OS from one of the affected manufacturers (which is basically all of them).
milicent_bystandr@lemm.ee
on 07 Dec 2023 04:48
collapse
But I mean, this attack can go cross-OS? I.e. a successful attack on one OS on the dual boot machine can, via UEFI infect the other OS?
Yes, it can execute code regardless of OS installed because it persists on the Mainboard and loads before any OS, making it possible to inject code into any OS.
milicent_bystandr@lemm.ee
on 07 Dec 2023 17:52
collapse
Don’t worry, I’m just on standby.
kugmo@sh.itjust.works
on 06 Dec 2023 22:56
nextcollapse
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
on 06 Dec 2023 23:56
collapse
Correct.
LainOfTheWired@lemy.lol
on 06 Dec 2023 23:25
nextcollapse
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
JakenVeina@lemm.ee
on 06 Dec 2023 23:44
nextcollapse
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
on 07 Dec 2023 00:09
nextcollapse
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: 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.
UEFI is flawed for sure, but there’s no way that any remaining patents on FAT32 haven’t expired by now.
OmnipotentEntity@beehaw.org
on 07 Dec 2023 05:46
collapse
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.
HiddenLayer5@lemmy.ml
on 07 Dec 2023 09:58
collapse
Why software patents are a leech on software development: exhibit number
4,294,967,295.
interceder270@lemmy.world
on 07 Dec 2023 00:47
nextcollapse
Less is more. I feel we’ve forgotten that so worthless designers can justify their useless existences.
Shareni@programming.dev
on 07 Dec 2023 10:18
collapse
Yeah, the designers were lobbying to force showing hardware ads during boot…
Less is more.
Listen to your own maxim.
HiddenLayer5@lemmy.ml
on 07 Dec 2023 09:28
nextcollapse
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?)
planish@sh.itjust.works
on 07 Dec 2023 03:07
nextcollapse
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.
Truck_kun@beehaw.org
on 07 Dec 2023 06:07
nextcollapse
I actually am in the market for a new mobo and cpu.
Are there any mobo’s nowdays that don’t use UEFI? I just want an old traditional style BIOS with a jumper to restore it from a ROM chip if I get any malware, so I can actually trust my hardware.
I did force myself to deal with UEFI for the sake of windows, but gaming has gotten good enough on Linux, I don’t actually need to dual boot windows anymore.
Am I asking too much?
randombullet@feddit.de
on 07 Dec 2023 06:27
nextcollapse
Some enterprise grade stuff still use BIOS. But I haven’t messed with one for over 6 years
BellaDonna@mujico.org
on 07 Dec 2023 20:48
collapse
More like they have an emulated BIOS mode that is still part of UEFI.
That’s called CSM, and Intel removed it in late 2020. I’m not sure if AMD still has it, but they still have S3 sleep afaik. Go Team Red for your next buy, I am too.
So I don’t get it, I have my entire boot image in a signed EFI binary, the logo is in there as well. I don’t think I’m susceptible to this, right? I don’t think systemd-boot or the kernel reads an unsigned logo file anywhere.
(Using secure boot)
clmbmb@lemmy.dbzer0.com
on 07 Dec 2023 07:49
collapse
This is way before reaching your bootloader. It’s about the manufacturer logo that’s displayed by UEFI while doing the whole hardware initialization.
That’s… Stored in the EFI partition or changeable in userspace?
clmbmb@lemmy.dbzer0.com
on 07 Dec 2023 11:44
collapse
Depending on how the UEFI is configured, a simple copy/paste command, executed either by the malicious image or with physical access, is in many cases all that’s required to place the malicious image into what’s known as the ESP, short for EFI System Partition, a region of the hard drive that stores boot loaders, kernel images, and any device drivers, system utilities, or other data files needed before the main OS loads.
Right, I know EFI images are stored in the EFI partition, but with secure boot, only signed images can be executed, so they’d need to steal someone’s signing key to do this.
olafurp@lemmy.world
on 07 Dec 2023 08:41
nextcollapse
On Linux/Mac you have no use sudo. For sudo you need a password.
This thing will make it very easy to make a rubber ducky though.
HiddenLayer5@lemmy.ml
on 07 Dec 2023 09:47
collapse
Would be pretty easy to pull off if you had hardware access. Just boot from a flash drive and drop the exploit from there.
Even if their OS is full disk encrypted, this can easily inject a backdoor or just keylog the bootup password prompt.
HiddenLayer5@lemmy.ml
on 07 Dec 2023 09:06
nextcollapse
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.
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
on 07 Dec 2023 16:45
nextcollapse
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,
I want to insert my own logo into the boot process, and I want these ducking vendors to properly validate and assess their mother ducking software. But nooo, penetration tests and any remediations are too expensive for these pieces of bit. Why do it when you can just stick your dick in everyone’s face, right?
azertyfun@sh.itjust.works
on 08 Dec 2023 00:10
collapse
??
With BIOS, it goes “Motherboard Logo -> OS Logo”
With UEFI, it goes “Motherboard Logo -> Motherboard Logo”
Sure, it’s more consistent, but the alternative is not user unfriendly, the only people it’s unfriendly to is the marketing wankers at Dell, Lenovo, Acer, etc.
HiddenLayer5@lemmy.ml
on 07 Dec 2023 09:17
nextcollapse
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?
threaded - newest
This is the best summary I could come up with:
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.
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 participating companies comprise nearly the entirety of the x64 and ARM CPU ecosystem, starting with UEFI suppliers AMI, Insyde, and Phoenix (sometimes still called IBVs or independent BIOS vendors); device manufacturers such as Lenovo, Dell, and HP; and the makers of the CPUs that go inside the devices, usually Intel, AMD or designers of ARM CPUs.
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.
LogoFAIL is a newly discovered set of high-impact security vulnerabilities affecting different image parsing libraries used in the system firmware by various vendors during the device boot process.
The original article contains 663 words, the summary contains 232 words. Saved 65%. I’m a bot and I’m open source!
Summary does not contain the actual vulnerability or exploit.
Because there really isn’t one, lol.
By the time an attacker has a write access to your boot permission everything else is kinda fucked already.
This is worse than many, since it persists across reinstalls and even potentially drive swaps, and fools systems such as secure boot.
If it’s only on the ESP, it won’t persist across reinstalls, and definitely not drive swaps.
But I do see mentions of attacking via firmware capsule. If that works, then yes, that will persist.
ESP is usually not cleared on a reinstall unless somebody takes the extra step to do so. Since each OS has its own directory within the ESP their installers don’t push it. I was mostly referring to modification in firmware though.
Yes, an attacker with write access to boot already compromised the entire OS and data. Usually replacing the storage or reinstalling the OS would get rid of the attacker. But this exploit happens early in the boot process, before the OS even loads.
This means the only way to ensure a network remains uncompromised after an attack is physically destroying any infected devices or replacing their mainboard.
Good bot
damn 😱
Don’t panic!
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?
The worst part it persists through reinstalls (if i understood correctly)
This is also my understanding, at least of you keep the EFI partition.
It can outlast those too.
Boy do I love the future.
It’s reminiscent of boot sector viruses in the DOS days.
Since the EFI partition is unencrypted, physical access would do the trick here too, even with every firmware/software security measure.
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.
Unless a proper secure boot + FDE setup is in place.
i wonder if containerized firefox (eg snap/flatpak) will
So if I have my computer set that it needs a sudo password for most changes am I good?
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.
Thanks for the answer. Unless my dog learns how to code I think I’m safe from anyone getting physical access
As a hacker imma start teaching dogs to code as part of my breakin process, sorry bud
Introduce him or her to FidoNet.
Ah, so the next Air Bud movie will be what, Hack Bud?
“There’s nothing in the specifications that says that a dog can’t have admin access.”
“Nothing but 'net!”
Unless they find another way to escalate privileges… A bug, a random binary with suid, etc
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?
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.
If it can execute in ram (as far as I understand, they’ve been talking about fileless attacks, so… Possible?), it can just inject whatever
Addit: also, sucure boot on most systems, well, sucks, unless you remove m$ keys and flash yours, at least. The thing is, they signed shim and whatever was the alternative chainable bootloader (mako or smth?) effectively rendering the whole thing useless; also there was a grub binary distributed as part of some kaspersky’s livecd-s with unlocked config, so, yet again, load whatever tf you want
Last time I enabled secure boot it was with a unified kernel image, there was nothing on the EFI partition that was unsigned.
Idk about the default shim setup but using dracut with uki, rolled keys and luks it’d be secure.
After this you’re protected from offline attacks only though, unless you sign the UKI on a different device any program with root could still sign the modified images itself but no one could do an Evil Maid Attack or similar.
The point with m$ keys was that you should delete them as they’re used to sign stuff that loads literally anything given your maid is insistent enough.
[note: it was mentioned in the arch wiki that sometimes removing m$ keys bricks some (which exactly wasn’t mentioned) devices]
If I can replace a file in your EFI, how hard would it be to sign the same file.
Well, it rules out an evil maid attack and maybe jumping over a dual boot setup.
See, I knew there were other reasons I wouldn’t touch secure boot lol
The idea is also that a compromised system will remains compromised after all storage drives are removed.
.
Yeah, if someone has write access to your boot partition then you're kind of already screwed.
I wonder if old BIOS are vulnerable…
Nope, they aren’t as universal as EFI. I think the closest comparable attack vector for “old tech” is a bootsector virus.
So, does disabling the boot logo prevent the attack, or would it only make the attack obvious?
.
Usually you can, though the setting might be listed under something like “show diagnostic during boot”.
If you have access to replace the logo file, you probably have access to enable it as well.
Not necessarily, I guess. They’re talking about a firmware upgrade of sorts, and, at least on the machines I own(ed), performing it didn’t reset user settings (which disabling the logo is)
I can’t believe stupid, pointless marketing crap didn’t have the best of the best working to ensure security.
Fyi if someone had physical access / administration access due to another vulnerability to your machine they can exploit it, news at 11:00
Would resetting bios clear this?
More like reflashing entirely or just changing the image. Alternatively, you can often disable showing the.logo somewhere in the settings.
What’s known as resetting bios is more like removing the stuff saved in CMOS, AFAIK
Most fastboot options dont show the logo until windows bootloader comes along.
Though i am not sure how or why the logo is displayed when windows loads? Is that the same image? Loaded and displayed again or just didnt clear the display?
Loaded and displayed again, yes. It is stored in the BGRT table.
.
I think so, but there can probably be some vendor-specific differences, like storing the image in a place that doesn’t get overwritten. For example, thinkpads provide a way to supply your own image, and when installing updates after that you’re asked if you want to keep it. But yeah, the update should neuter it anyways
BIOS booting stays winning
Me using an old PC with BIOS instead of UEFI: 😏
Also known as using a pc with unpatched cpu vulnerabilities
gigachads use
mitigations=offanywaysMakes it go fast
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.
.
Is this potentially useful to me? Since it is persistent, can I use it on this motherboard I have over here that insists on using UEFI even if I do not want to?
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?
It would effect any UEFI based system regardless of OS from one of the affected manufacturers (which is basically all of them).
But I mean, this attack can go cross-OS? I.e. a successful attack on one OS on the dual boot machine can, via UEFI infect the other OS?
Yes, it can execute code regardless of OS installed because it persists on the Mainboard and loads before any OS, making it possible to inject code into any OS.
Aaa! Name thief!
Don’t worry, I’m just on standby.
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?
Correct.
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
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?
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: 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.
UEFI is flawed for sure, but there’s no way that any remaining patents on FAT32 haven’t expired by now.
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.
Why software patents are a leech on software development: exhibit number 4,294,967,295.
Less is more. I feel we’ve forgotten that so worthless designers can justify their useless existences.
Yeah, the designers were lobbying to force showing hardware ads during boot…
Listen to your own maxim.
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?)
Yes.
Said no one ever.
I actually am in the market for a new mobo and cpu.
Are there any mobo’s nowdays that don’t use UEFI? I just want an old traditional style BIOS with a jumper to restore it from a ROM chip if I get any malware, so I can actually trust my hardware.
I did force myself to deal with UEFI for the sake of windows, but gaming has gotten good enough on Linux, I don’t actually need to dual boot windows anymore.
Am I asking too much?
Some enterprise grade stuff still use BIOS. But I haven’t messed with one for over 6 years
More like they have an emulated BIOS mode that is still part of UEFI.
That’s called CSM, and Intel removed it in late 2020. I’m not sure if AMD still has it, but they still have S3 sleep afaik. Go Team Red for your next buy, I am too.
No, and trying to use a pure BIOS system these days is a headache.
You can always just reflash your firmware from a trusted OS via FWUPD.
So I don’t get it, I have my entire boot image in a signed EFI binary, the logo is in there as well. I don’t think I’m susceptible to this, right? I don’t think systemd-boot or the kernel reads an unsigned logo file anywhere. (Using secure boot)
This is way before reaching your bootloader. It’s about the manufacturer logo that’s displayed by UEFI while doing the whole hardware initialization.
That’s… Stored in the EFI partition or changeable in userspace?
(from the article)
Right, I know EFI images are stored in the EFI partition, but with secure boot, only signed images can be executed, so they’d need to steal someone’s signing key to do this.
On Linux/Mac you have no use sudo. For sudo you need a password.
This thing will make it very easy to make a rubber ducky though.
.
Would be pretty easy to pull off if you had hardware access. Just boot from a flash drive and drop the exploit from there.
Even if their OS is full disk encrypted, this can easily inject a backdoor or just keylog the bootup password prompt.
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.
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.
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,
I want to insert my own logo into the boot process, and I want these ducking vendors to properly validate and assess their mother ducking software. But nooo, penetration tests and any remediations are too expensive for these pieces of bit. Why do it when you can just stick your dick in everyone’s face, right?
Fuck.
Tell me more about this screaming clown penis option…
You gotta hold ctrl alt shift honk at power up.
??
With BIOS, it goes “Motherboard Logo -> OS Logo”
With UEFI, it goes “Motherboard Logo -> Motherboard Logo”
Sure, it’s more consistent, but the alternative is not user unfriendly, the only people it’s unfriendly to is the marketing wankers at Dell, Lenovo, Acer, etc.
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?
coreboot exists
I may be wrong, but does it mean that if someone is able to modify my uefi - they would be able to inject virus in booting image?
Yes, that is exactly the implication
is it common practice to have a web browser or media player running with elevated permissions? seems like a strange thing to do…
Very unlikely unless there is an elevated privilege exploit to use alongside this
We need more machines that support coreboot. These proprietary firmware vendors have been getting rich off making our machines worse for too long.
A flashed Chromebook is an accessible option
mrchromebox.tech
i use coreboot but i’d prefer libreboot if a gaming level system with linux supported it. Are their any? I ask to the masses, not you specifically lol