@evochkauwu Via trivial fuzzing it has been determined that every single proprietary UEFI implementation uses custom jpeg and/or png rendering libraries that are full of vulnerabilities.

I guess I came across this myself years ago without realizing it when I flashed a UEFI image with a custom png that the library couldn't handle and therefore crashed the UEFI on boot (the dualbios recovery was automatic).

As it turns out, it seems you can craft an image file containing UEFI-specific exploit instructions, that the UEFI jumps to and therefore has ring -1(?) access, which is complete computer compromise and of course all the signing keys (which the manufacturer holds) are completely bypassed, as you can't exactly allow for a custom boot logo without the logo being unsigned (such could have potentially been avoided if the user could use their own keys to sign the whole UEFI including their custom logo, but it's about restricting the user with digital handcuffs and not security it seems)0.

UEFI also has a slightly-standardized filesystem interface and it seems that for many UEFI implementations, if a logo image is copied to the correct folder, that'll get copied to the SPI flash automatically.

This means that writing a UEFI rootkit that reliably works on most computers is mildly difficult, as pretty much all UEFI's seem to use the same shoddy UEFI codebase and crafting a few different images (with the same payload) for the few different buggy image rendering libraries in use isn't very difficult.

This means less security than proprietary BIOS's, as a reliable, broadly generic BIOS rootkits are very difficult to write, as every single motherboard has a different way to flash the SPI flash (with some containing EC software in one section that you want to avoid writing anything but a EC rootkit to if you don't want to brick the computer) and BIOS's don't really offer a somewhat generic API interface like UEFI does (a lot of proprietary BIOS's seem to be based off a version from "American Megatrends", but each manufacturer seems to have made heavy modifications).


A few proprietary UEFI's don't seem to be affected by not allowing for custom logos, but I doubt many of them bothered to sign all the sections, including the "non-executable" image and text data, so slightly more complicated exploits for those computers are likely to be possible too.


Free BIOS's like GNUboot seem to be a better idea really, as you can flash a known good image to the SPI flash chip and lift the WP pin and put tape under and you're looking pretty good.

An article with more details is here (they write "Windows and Linux" but the OS or kernel in use has no relevance to the exploit); https://arstechnica.com/security/2023/12/just-about-every-windows-and-linux-device-vulnerable-to-new-logofail-firmware-attack/