20 ms·
LogoFAIL: Secure Boot bypass with manipulated boot logos
- Kim_Bruning 3y agoWho knew that non-free UEFI might be a bad idea? /s
- retrochameleon 3y agoWhat do you mean?
- somat 3y agoThe really neat thing about having the source code. Is that it implies that you have the tool chain to build that source code. This is not always true, However because the source is mostly useless without a way to build it, it is mostly true. With the unfortunate note that firmware often has a nasty lovecraftian inspired toolchain. Once you have the source and the toolchain to build it. Now, not only are you in a position to fix your own bugs, all users of that hardware are in a position where they can co-operate to fix and share updates. Security update could be provided forever if people are willing to work on the problem. Having opensource firmware is a great enabler. The neat side effect of open source development is that it usually ends up taming the unholy tangle that proprietary toolchains end up becoming. Something, something.. mumble... about how when random joe is expected to compile a project that project starts shifting into a form that random joe can compile.
- jopsen 3y ago> Something, something.. mumble... about how when random joe is expected to compile a project that project starts shifting into a form that random joe can compile. It's amazing what a little sunlight can do :)
- nine_k 3y agoIt seems that running anything for what you don't have source code becomes more and more of a liability. Not enough eyeballs, fuzzers, white-hat cracking attempts means a lot of serious risk.
- joombaga 3y agoIs this completely mitigated by disabling boot logos? Edit: What I mean is, do the image parsers still run if boot logos are disabled?
- nine_k 3y ago> Image parsers in UEFIs from all three major IBVs are riddled with roughly a dozen critical vulnerabilities I'd suspect that an image parser is only involved when a logo needs to be displayed. So it looks like a great way to lower the chances of triggering these vulnerabilities. I'll switch off mine. OTOH if an image parser is also invoked when the logo is updated, to check that it parses correctly, this won't be enough :(
- roywiggins 3y agoI guess I wouldn't be surprised at all if some BIOSes always parse the logo and the switch just turns off the display.
- hollerith 3y agoNo because an attacker who got control could undisable them, then become persistently entrenched in your system such that you remain compromised even if you reinstall your OS.
- joombaga 3y agoRight. I was more curious about if the image parsing code was still vulnerable while boot logos are disabled.
- hollerith 3y agoOh, you mean disabled in the motherboard's firmware settings. I hadn't consider that interpretation of your question. ADDED. I disabled it in my ASUS motherboard's settings.
- grumpybychoice 3y ago[dead]
- yunohn 3y agoI wasn’t aware that one could just copy paste and replace arbitrary UEFI boot files from user space? I was under the impression that they are in non-mounted partitions controlled by the system.
- airhangerf15 3y agoYou can comment out /boot/efi on Linux from the fstab, and only mount it when you need to run a grub update. I'm not sure which Linux systems keep it mounted by default (I suspect most of them do, mostly for grub updates) I don't think Windows mounts it by default anywhere. At the same time, on Windows or Linux, you would need root/Administrator access to inject this, wouldn't you? You could inject any binary. I guess the thing here is that if you just replace the bootloader, secure boot should stop the boot process with your unsigned binary. With this exploit, you can replace the logo and it doesn't do the same signature check?
- yjftsjthsd-h 3y ago> I guess the thing here is that if you just replace the bootloader, secure boot should stop the boot process with your unsigned binary. With this exploit, you can replace the logo and it doesn't do the same signature check? Exactly; most vendors apparently check signatures on anything officially executable but will blindly load any picture you hand them.
- yunohn 3y agoBut you would need sudo access to create a malicious bootloader partition and edit fstab. And indeed on Windows, I’ve never seen the bootloader mounted. Maybe I’m missing something in the disclosure?
- beeboobaa 3y agoYou can just write to the disk as administrator on windows. No need to mount anything though you could probably do that too.
- pjc50 3y agoDoes this successfully bypass "secure" boot? Quite a big deal if true. On the other hand now I know it's possible I'm tempted to replace my boot logo with a custom one..
- nine_k 3y agoYes :( > 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. Just checked; my laptop mounts /sys/firmware/efi/efivars and /boot/efi rw by default. Time to fix this. Not a huge defense against an RCE + priv escalation somewhere, but at least would help against fat fingers under sudo.
- notabee 3y agoPoettering is very convinced that this is not a bug. https://news.ycombinator.com/item?id=11008771 https://news.ycombinator.com/item?id=11008771 https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
- nine_k 3y agoI've read the second thread today. I'm running a "Poettering-free" distro (Void Linux), but it does not have this mitigation either.
- anaisbetts 3y agoI mean, I agree with him - read-only mounts are not a security boundary, user accounts and permissions are the security boundary.
- nine_k 3y agoGuard rails are not a security boundary, but are helpful nevertheless. You can still do that, but it becomes harder to do by mistake.
- Voultapher 3y agoI'm shocked! Firmware vendors, the last bastion of high quality memory-safe C code, solving complex problems. Code firmly audited and formally verified to the highest degree. And now you tell me these people, with the highest known software quality got "parsing image formats" wrong? It's truly zebras all the way down https://youtu.be/fE2KDzZaxvE https://youtu.be/fE2KDzZaxvE
- seemaze 3y agoThank you for that reference. As someone outside of tech, I still found Bryan Cantrill's presentation to thoroughly engaging and entertaining.
- kbenson 3y agoYou'd enjoy most his talks, even if you don't understand the source material. They're half anecdotes and bashing Oracle in a very entertaining way.
- pwdisswordfishc 3y agoI fear your sarcasm may be a bit too subtle.
- nine_k 3y agoOn topic: does the open-source Coreboot fare any better here? (I hope it does; the article does not mention it.)
- est31 3y agocoreboot just initializes the hardware, the logo is something that the payload displays: https://www.coreboot.org/Payloads https://www.coreboot.org/Payloads The most typically used payload is u-boot: https://docs.u-boot.org/en/latest/ https://docs.u-boot.org/en/latest/ u-boot supports specifying splash screens via "splashfile", but it seems only bmp and maybe some raw image format are supported: https://github.com/u-boot/u-boot/blob/2f0282922b2c458eea7f85c500a948a587437b63/common/splash_source.c#L4 https://github.com/u-boot/u-boot/blob/2f0282922b2c458eea7f85... In other words, no support for png, which this exploit uses :). That doesn't mean that coreboot/u-boot aren't written in C though which is a language known for its vulnerabilities.
- beeboobaa 3y agoYet again we're shown that secure boot and TPMs are security theatre designed for DRM and not to protect you, the user.
- nine_k 3y agoA TPM is a pretty useful thing, but all it can do is to securely store secrets.
- eimrine 3y agoTo securely store some secrets from the user?
- Avamander 3y agoFrom everyone, if needed.
- nine_k 3y agoYes. E.g. there are cases when it's much better to lose your disk encryption key and the entire disk's contents with it than to let a third party see it. So the disk encryption key may live in a TPM. This is supported by LUKS, for example.
- mschuster91 3y agoStill pointless when the key can be sniffed in cleartext by intercepting the communication between the TPM and the CPU [1]. You should always combine it with something only known to the user (i.e. a passphrase). The only attack TPM-backed disk encryption prevents is someone imaging the disk. [1] https://blog.scrt.ch/2021/11/15/tpm-sniffing/ https://blog.scrt.ch/2021/11/15/tpm-sniffing/
- roywiggins 3y agoPutting an image parser in the first stage of boot seems like a mistake in the first place tbh. Surely you could skip that and just bake the decoded image into the firmware? Or is this all so vendors can rebrand their BIOS without having to rebuild and sign it?
- reginaldo 3y agoYou nailed it. This is so vendors can rebrand without having to rebuild and re-sign.
- Arnavion 3y agoIIUC There are two vectors: 1. Logos in EFI binaries (OS, bootloader, shell, etc), not the UEFI firmware logo itself. For these, "bake it into the firmware" is not relevant because these are just files that anything, such as malware, can drop into the ESP. 2. The UEFI firmware logo itself. This would only be updated by firmware updates, which ought to be signed, but apparently these vendors put the logo in non-signed sections, so malware could edit a pending update to use a malicious image.
- tadfisher 3y agoLenovo ships the standard Phoenix shell app named ShellFlash.efi (which calls itself ShellFlash64). One of its CLI flags is to flash the UEFI logo. The Lenovo BIOS package includes instructions to update the logo by dropping the image file in the ESP where their updater (BootX64.efi) can find it. So flashing unsigned logo images is supported and intended behavior here.
- jeroenhd 3y agoFrom what I can tell by the demo video, the Windows process seems to be injecting the bitmap before calling a reboot without calling into the flash utility. I wish I could put up a nice customised image without having to mess with firmware files. It's kind of stupid to include a logo feature but then to remove the image file every time you install an UEFI firmware update.
- forward1 3y agoThe risk is "image parsers in UEFIs ... are riddled with roughly a dozen critical vulnerabilities" but what is the attack vector? Has a dropper been identified? Or is this an academic finding only?
- roywiggins 3y ago> There’s no indication that LogoFAIL vulnerabilities have been actively exploited in the wild, but there’s also little way one would know, since infections are so hard to spot using traditional tools and methods.
- nine_k 3y agoTheir idea of an attack vector: local exploit or phishing -> privilege escalation -> accessing the UEFI partition. Say, an installer of a pirated game might pull this off, and turn your machine into a permanent botnet node, incurable by standard means, and maybe undetectable. But this is a low-value target; a usually dormant, stealthy fileless malware on a laptop that belongs to a CEO or a high-ranking government official may be much more insidious and impactful.
- johnea 3y agoUEFI is just another M$ abomination 8-( In this specific vulnerability, I wonder how possible it is to modify that boot logo remotely? Wouldn't exploiting this vuln require local access? As in all things, open firmware is the way to go: https://www.linuxboot.org/ https://www.linuxboot.org/ https://libreboot.org/ https://libreboot.org/ https://www.coreboot.org/users.html https://www.coreboot.org/users.html
- forward1 3y agoDo Libreboot supported hardware devices, which appear quite old, still receive CPU patches? If not, it is probably time to stop using it. Coreboot may give you a fighting chance however.
- justaj 3y agoIIRC LB supports microcode updates, but I don't think older CPUs will receive new microcode updates from CPU vendors. Then again, newer CPUs have a host of other problems, like only supporting platforms where rolling your own boot firmware / UEFI is next to impossible. Personally I think the CPU has a much lower attack surface than something like UEFI (microcode updates are also pretty tiny), so I would rather have an outdated CPU than an outdated / vulnerable UEFI implementation.
- forward1 3y agoDisagree entirely. With an outdated CPU, you could be owned just by running Javascript on the wrong site. Not so with a vulnerable UEFI/BIOS, that requires additional privesc as is seen here.
- justaj 3y agoHmm, I see your point. Couldn't such CPU bugs be patched / mitigated in software (which would then incur some performance penalties) ?
- WesolyKubeczek 3y agoOkay, how do I even change the boot logo in BGRT so it persists across boots? From userspace, no less? And how do I turn them off? On your generic dell/lenovo boxes I doubt it's even possible.
- nine_k 3y agoDo you even run installers from not entirely trusted third parties, or curl | sudo bash type of thing? That could sneak in.
- WesolyKubeczek 3y agoYes, but how do I do it if I want to do it for my own amusement?
- p_l 3y agoLenovo uses Phoenix provided tool that will prepare compatible graphic image into update capsule and pass it to flasher program (embedded in the firmware)
- WesolyKubeczek 3y agoSo that would require an authenticated program execution, a reboot, a reflash, and a reboot again. Hardly unnoticeable. I think EFI updates can be disabled in most UEFI setup programs by the administrators, so they only reenable them explicitly when doing the actual, you know, EFI updates. I thought that was possible by mucking in a RAM region that would persist across warm reboots and UEFI would pick up the logo from there.
- p_l 3y agoYou can put an update capsule in that region and it will be picked on reboot. Another option is putting a file in ESP then telling EFI with a special call that there's an update to be applied (special call is also needed to inform EFI about the memory update method). Windows Update uses those to deliver firmware updates on behalf of vendors.
- forward1 3y agoThanks. My take is on this is root access -> stealthy bootkit. Further demonstrates "secure" boot and similar DRM is theater only.
- AshamedCaptain 3y agoOn the defense of the secure boot illusionists, though, I'm going to imagine that _anyone_ who was actually concerned about secure boot working as intended would have disabled the running kernel from accessing UEFI variables and the UEFI system partition.
- k8svet 3y agoAFAIK, while supporting XBOOTLDR, the systemd project still encourages /boot to be on the ESP if possible. Personally, I don't understand why they advocate this. Beyond separation of concerns and situations like this, it also seems more realistic to advocate for XBOOTLDR style deployments in the face of dual boot systems and Windows creating an anemic ESP nowadays.
- gunapologist99 3y ago> Personally, I don't understand why they advocate this. It seems easier to explain if you don't mind choosing from a nice range of conspiracy theories about what systemd is and why it has spread like a virus.
- amluto 3y ago> disabled the running kernel from accessing UEFI variables and the UEFI system partition. How exactly do you propose doing that? I suppose you could see if OPAL can block writes to the ESP, but that does nothing about efi vars.
- AshamedCaptain 3y agoKernel lockdown
- bawolff 3y agoSo in secureboot, do images used not to be signed? Otherwise how does this work? That seems like an odd flaw
- nine_k 3y agoThe images are in the unsigned section :( It's more convenient to OEMs and corporate customers this way :(
- eimrine 3y agoWill this help in de-obfuscating the notorious Intel ME and/or its analogs?
- doublerabbit 3y agoAlthough, "file to hard-drive" isn't possible if you use BitLocker, LVM or ZFS Encryption. More a reason too.
- pavon 3y agoThose don't encrypt the EFI system partition, which is where the image in question is stored.
- doublerabbit 3y agoYes thats still vulnerable. But the drop and place on to a hard drive isn't so possible.
- pavon 3y agoThe BIOS never reads the logo image from OS partitions on a drive. It either gets it from firmware stored in flash on the motherboard, or from the EFI system partition on the harddrive. Thus dropping the logo file on ESP partition or reflashing the firmware are the two attack vectors. Writing to other partitions is not an attack vector for this vulnerability, so encrypting those partitions does not protect against it.
- doublerabbit 3y ago> Writing to other partitions is not an attack vector for this vulnerability I'm not saying that this is the attack vector for this vulnerability. I'm merely stating that utilizing the exploit to place a file as the video shows, wouldn't be possible if your main C: /root partition is encrypted. If your main drive partition is not encrypted, than that can lead to the ability to dropping a file on the desktop. I suppose, yes, if someone codes "wait_until_encryption_is_completed" function.
- jmclnx 3y agoI still use BIOS and I hopefully never be forced to use UEFI or Secure Boot. Again RMS and Theo both came out against UEFI (IIRC). But $ mean more in security. > that have lurked for years, if not decades, in Unified Extensible Firmware Interfaces responsible for booting modern devices that run Windows or Linux What does this mean, "decades" ?? I kind of doubt it. I guess we cannot have a article without sensationalism.
- yjftsjthsd-h 3y agoIf BIOS is immune to this, it's only by coincidence; there's no reason to think older firmware that allows the user to set the boot logo isn't equally riddled with vulnerabilities.
- jmclnx 3y agoLast I heard, BIOS firmware is forced to be 64k (or 128k), but that limit could have changed over the years. Not much of a logo would fit with that limit. edit: just checked, the BIOS in my newest laptop ~10 years old is 128k. But the ROM size is 12M which is interesting. I can enable UEFI so I can only guess the remaining space is used for that.
- yjftsjthsd-h 3y agoI mean, I don't know how it's stored, but it does still have a boot logo. I guess if it only supports really tiny logo files for whatever reason that reduces the amount of code an attacker can give it, but that doesn't feel like a very good defense. Edit: Oh, or if the older firmwares only supported a logo that was hardcoded into the image and that can't be updated separately, that might help. Still coincidental, though; you certainly could have a user-controlled logo with BIOS, and as the article notes, there are UEFI implementations that also hardcode the logo.
- p_l 3y agoIn reality you have UEFI and the 128k is 16bit shim code of the Compatibility Support Module that emulates BIOS interfaces. UEFI Class 1 devices (which had hardcoded CSM and didn't allow access to UEFI APIs from bootloader or OS) started shipping as early as 2005 - because it made it much simpler to build firmware especially when you're supposed to integrate complex vendor specific code (for example from Intel). Even before that, it was not uncommon for BIOS to actually be much bigger than 128k. Logos were also common as part of BIOS. Hell, 1990s had a bunch of BIOSes with GUIs with mouse support. Some even tried to emulate look&feel of Windows. At least UEFI provides a graphics toolkit that supports rendering to both GUI and serial port, so you don't have to deal with BIOSes that can't be connected to over serial because they need VGA raster output...
- deleted 3y ago[deleted]
- instagib 3y agothere are 3 paths. 1. placing logo into ESP (EFI System Partition) via admin privileges 2. Bios update tool 3. When there is no expected way to customize the logo, it is still possible via physical attack vector: just with an SPI flash programmer if a logo is not covered with any hardware-based Verified Boot technology like Intel Boot Guard or AMD Hardware-Validated Boot “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. “ https://binarly.io/posts/finding_logofail_the_dangers_of_image_parsing_during_system_boot/ https://binarly.io/posts/finding_logofail_the_dangers_of_ima...
- LoganDark 3y agoWhat's wrong with simply not running malicious software? Is it supply chain attacks?
- acdha 3y agoIt means that any bug which lets an attacker get privileged access is now a potentially hard to recover compromise below the operating system kernel, but Secure Boot still passes. That means a compromise might no longer be recoverable short of trashing the hardware, and it could be triggered in many ways from some kind of exploit to having a few minutes alone with the hardware to tricking someone into running an installer.
- neilv 3y ago> Image parsers in UEFIs from all three major IBVs are riddled with roughly a dozen critical vulnerabilities that have gone unnoticed until now. If your code has a dozen vulnerabilities, it has more than that. Also, every time I see a 2D image library, I assume it almost certainly has vulnerabilities. There's something magical about the task of coding 2D image libraries, such that it really calls out how bad we are at writing correct code (especially in C).
- hulitu 3y ago> (especially in C). I thought iMessage was written in ObjectiveC. /s
- Guvante 3y agoAs easy as it seems to be to just include an image decoder it feels like "must be a specific size bmp file" is a perfectly acceptable solution here.
- DaiPlusPlus 3y ago...but what if the "must be a specific sized BMP file" rule is because if you were to flash the eprom with, say, a PNG file it meant you suddenly got root over Intel's Management Engine in your CPU?
- hsbauauvhabzb 3y agoParent is suggesting logic which refuses to parse png standard, not extension/mime-type validation. Presumably a precision formatted png uploaded as a bmp will just render as a starry mess of color, assuming format confusion is possible within the bmp standard.
- Guvante 3y agoBMP isn't encoded at all. Effectively width + height followed by row ordered pixels. Hard code file length and fail if the width or height are different. Copying pixels to the screen is hard to mess up.
- fortran77 3y agoThis should say “just about every UEFI device”. The problem has little to do with any particular OS.
- reginaldo 3y agoI wonder if anyone tried this in Android, which also has a logo partition. Maybe not the flagship phones, but if I were to guess, I'd guess the TV sticks and other Android streaming devices might have similar issues.
- peppermint_gum 3y agoIf a local vulnerability that requires administrative privileges to exploit is "high impact", I wonder how they would classify remote code execution. Super duper high impact? This of course needs to be patched, but it's way overblown. This vulnerability alone provides no attack vector, you need other vulnerabilities to be able to replace the logo.
- gunapologist99 3y agoBut an RCE goes away as soon as you re-OS. Once your UEFI is pwned, you might as well pitch the box in the rubbish bin.
- planede 3y agoThe attack defeats the whole premise of security in "secure boot". It's high impact in relation to that. As a user I don't care too much about "secure boot" and its threat model, and I assume you don't either.
- 1970-01-01 3y agoNobody enjoys dealing with UEFI. Its a very ugly mess of a standard that is an order of magnitude more complicated compared to BIOS.
- phendrenad2 3y agoActually, while you're technically correct, most of the complexity of UEFI is just fluff that no one actually uses. I think it only exists so that EFI compliance is a huge pain to fully implement, so that companies have to pay the standards body for consulting fees.
- NelsonMinar 3y agoSecureBoot and UEFI is a regular pain in my ass. Just yesterday I couldn't run memtest86+ on a new computer because of it. I'm installing a bunch of Linux VMs these days and both on the real hardware and in the VM images UEFI and SecureBoot is a constant source of stress. And it doesn't even work? Because the firmware authors used crappy code to display marketing images? I want my tens of hours back.
- tryauuum 3y agoat least you can run VMs with traditional boot
- jeroenhd 3y agoDisabling secure boot takes like five seconds, I don't see what the big deal is.
- Lammy 3y agoI don’t feel comfortable depending on a vendor to expose that switch. Once all the Secure Boot infrastructure is built out all it will take is one more decision for them to stop giving me an option.
- upofadown 3y agoHow about we just have a physical switch that you have to activate to update the firmware? I don't care about the rest of the software in the boot chain, an attacker can just trojan any binary that runs as root to get the same effect. As a user I don't care about the distinction between boot and the rest of the time.
- TacticalCoder 3y ago> How about we just have a physical switch that you have to activate to update the firmware? A very long time ago motherboards were like that. You couldn't flash the firmware without first physically moving a jumper on the motherboard (btw what you're asking for typically would be done with a jumper, not a switch, AFAIK). I remember a very heated argument with a friend of mine when I got my first mobo that didn't require a jumper to be physically modified to be able to flash the firmware. I told him it was heresy and that, invariably, exploits would come. Note that these first mobo that could see their firmware flashed without requiring changing the position of a jumper had literally not confirmation asked of anything. You'd just flash the firmware by running an exe.
- jml7c5 3y agoChromebooks did this for a while; they had a write-protect screw on the motherboard that had to be removed to enter developer mode and/or flash custom firmware. Once you were done, you could reinsert the screw to lock it back down again.
- kogepathic 3y agoChromebooks still do this, they just swapped the write-protect screw for disconnecting the battery [1] or using a special closed-case debug (CCD) USB-C cable (which was discontinued and is now neigh impossible to buy). You can DIY your own though [2] [1] https://wiki.mrchromebox.tech/Firmware_Write_Protect https://wiki.mrchromebox.tech/Firmware_Write_Protect [2] https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/docs/ccd.md https://chromium.googlesource.com/chromiumos/third_party/hdc...
- mr_toad 3y ago
- userbinator 3y agoBit of a nothingburger IMHO, but as usual the corporate bootlicker types want to scare the hell out of everyone. Flashing the BIOS from within the OS never seemed like a good idea to me[1], but if you can do that then you can replace it with whatever you want. I also recall replacing the Energy Star logo with something more amusing was at one point a semi-common BIOS mod. [1] I remember the story of a certain company that included silent automatic background BIOS updates in the preinstalled bloatware of its laptops, and the subsequent large number of "I didn't do anything but reboot and now it won't even turn on anymore" reports.
- gunapologist99 3y agoNot exactly a nothingburger; this makes your machine once and always pwned.
- senectus1 3y agowith physical access to a device. anything is possible anyway
- userbinator 3y ago...until you reflash the BIOS.
- dishsoap 3y ago>this makes your machine once and always pwned. Well, no, it doesn't, but that's besides the point. These specific image decoding bugs are indeed a bit of a nothingburger in terms of the implications they give rise to. There's just no reason to overwrite the boot logo graphic and leverage these exploits if another (simpler) method of achieving the same end result exists, and often it does. For example, many systems to this day are shipped in a configuration such that you can disable write protections for certain ranges (or all) of the SPI EEPROM on which the firmware resides simply by changing some NVRAM variables (typically the variables correspond to (often hidden) 'BIOS settings' in common firmwares such as those from AMI or Phoenix), after which you can write contents of your choosing (eg. using Intel FPT) to the chip which will promptly be executed without any checks upon the next restart. This is by design, not even abusing any exploit or flaw in the software (of which there are plenty). If you want you can try it out on some of your own systems, for instance dump the firmware, extract (for example) the AMI setup menu form and simply run it through something like LongSoft's IFRExtractor[1] to locate the regions and offsets of said NVRAM variables, then try writing to them. It is true that the NVRAM regions for these settings (and others) are sometimes write protected or locked in such a way that you can't overwrite them after the firmware has started another program (eg. your bootloader), but often there are even ways around that. It's clear that firmware security is not always much of a concern for a surprising number of vendors currently shipping consumer computer systems / motherboards today. [1]: https://github.com/LongSoft/IFRExtractor-RS https://github.com/LongSoft/IFRExtractor-RS
- iforgotpassword 3y agoIt would be fun to collect all the exploits of EFI and secure boot and create some sort of super-bootloader-shim thingy that tries to work on as much hardware as possible where secure boot is enabled.
- butz 3y agoIs this the end of the "secure passkeys"?
- slicktux 3y agoEpic!
- to11mtm 3y agoThis does make me ask questions; namely, why the hell would anyone risk allowing compression more complex than RLE [0] in a firmware picture format? It's almost asking for trouble. [0] - Maybe there's something else out there that works better with similar ease of doing safely low level, would love to know other options!
- xnx 3y agoJohn Carmack suggests using something even more basic than RLE: "Media file parsing has been behind so many security issues. In many cases today, using completely raw data is very practical. No DCT. No ADPCM. No RLE. Just raw pixels/samples. There should be a widely agreed on header for modern raw data that is just a non-extendable struct." https://twitter.com/ID_AA_Carmack/status/1732519369362596262 https://twitter.com/ID_AA_Carmack/status/1732519369362596262
- yencabulator 3y agoNot "widely agreed" for sure but Suckless people proposed https://lists.suckless.org/dev/1407/23155.html https://lists.suckless.org/dev/1407/23155.html
- TobyFranklyn 3y ago[dead]
- mlindner 3y agoOxide Computer Company taking the moment to gloat: https://twitter.com/oxidecomputer/status/1732513396401012915 https://twitter.com/oxidecomputer/status/1732513396401012915 > Looks like we picked the right day to not have UEFI -- or a BIOS for that matter
- randombits0 3y agohttps://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... “Reflections on Trusting Trust”, Ken Thompson, August 1984
- josephcsible 3y agoDoes this have any actual significant impact? If you have enough access to exploit this, couldn't you already do a lot of harm even without it?
- MetaWhirledPeas 3y agoThat's what I'm trying to figure out too. I guess it's just harder to remove?
- _factor 3y agoA locked down encrypted at rest data center is much easier to break into when you can reboot a server with a usb and be in.
- MenhirMike 3y agoYet another reason why boot logos are stupid and the good old text-output is the way to go.
- immibis 3y agoGood, more people can own their own devices.
- jeremysalwen 3y agoI think
- eigenvalue 3y agoI’d be shocked if this whole thing wasn’t carefully coordinated and pulled off by the NSA. It’s the perfect attack— ubiquitous, low-level, and with plenty of plausible deniability and “aww shucks, memory usage C strikes again, waddya gonna do?” People should start trying to extract those images and comparing the SHA-256 hashes of the images. If you were going to exploit this you’d make it look the same visually and just put a low—level back door into the system to avoid raising any suspicions.
- comex 3y agoI’d be shocked if it was. Mostly because these are exactly the kind of bugs you find whenever you go digging into crusty old code. It would be more surprising if the image parsing code wasn’t vulnerable. And while these probably aren’t very hard to exploit, you would probably need to customize the exploit for the specific firmware and firmware version you’re targeting, making the bugs relatively unattractive to exploit en masse across a wide range of systems.
- saagarjha 3y agoWhy pull it off when you don't have to do anything and the bugs just fall out for you to use anyways?
- juunpp 3y ago> Today, the UEFI system firmware contains BMP, GIF, JPEG, PCX, and TGA parsers. Let's add more, guys, let's go. Webp -- no, that's too old...wait for it... JPEG XL.
- cryptonector 3y ago> It is also important to remember that attestation based on TPM has a lot of limitations in terms of runtime visibility. For sure. Secure attested boot at best attests all the code ostensibly loaded, but it can't do anything about vulnerabilities in that code or in code that's responsible for that loading. It's a mess.
- xentrope 3y agoPuts a bad taste in my mouth the only individual represented in the article is the CEO when they even call out that it was an individual who discovered it.
- planede 3y agoDoes UEFI have any mechanism to run some firmware code with reduced privileges? For example an image parser?
- 0xDEAFBEAD 3y ago>inside unsigned sections of a firmware update Why would you leave some sections of a firmware update unsigned??
- lenovosuper 3y agoI wonder if this could be used to remove Lenovo supervisor passwords and such. Could be a great way to reduce the amount of e-waste corporations create so that people can repurpose old corporate laptops.