Code-execution flaw in UEFI firmware affects most servers on planet Earth

28 points by aCaB

johnklos

I don't trust anything that runs before the kernel loads, which is why I always disable ethernet interface intialization in the BIOS, or use non-motherboard ethernet cards, or both.

I also don't use IPMI because it's horribly insecure by itself and requires a whole separate network, and because Supermicro doesn't think it's a security issue that if your battery on your motherboard dies and there's no link on your dedicated port on certain motherboards, your IPMI defaults to moving to the primary ethernet and to a state where it can be taken over by anyone on the local network.

It's really unfortunate that the response most people and corporations have is, "that's too unlikely to happen to matter". The fact is that it could happen, and it's much more likely to happen if someone has a reason to want it to happen.

We (the kind of people who are on this site) should always consider such things, yet for some reason it's not all that common.

For people who think that this really only effects servers, consider the fact that any device on your home network could be malicious. Your TV could be used to try to hijack rebooting machines. Personal machines are usually rebooted much more often than servers, after all.

kiyurica

I would even say that your network should probably be partitioned (with VLANs and whatnot) such that "trusted" machines like laptop and PC can't access "smart" devices and so on (perhaps only the Internet).

tuxes

The vulnerability, tracked as CVE-2026-97631, is a memory-corruption flaw in an ICMP component that attackers can exploit to execute malicious code that runs before the operating system and firmware can implement defenses like Secure Boot, which establishes a chain of trust for all code, including the Trusted Platform Module (TPM), loaded during boot.

Secure Boot isn't a defense against firmware vulnerabilities. If your chain-of-trust has a vulnerability, there's nothing subsequent stages can do.

Funnily enough, that's how the PS4 homebrew community operates: the PS4 boot security is undefeated, and so every boot the homebrewers have to run an exploit. Groundhog Day.

pegasus

I dream of a time when I will be able to just dd vmlinuz to /dev/bios_flash or some such ... all of these platform firmwares are becoming a burden and a liability.

johnklos

Corporate Linux interests don't even want to support x86 that's new enough that it's still being used at CERN right now. I would not want them deciding what hardware is worth supporting and what isn't.
sunshowers

This is roughly what we do at Oxide with our holistic boot. It has its tradeoffs — you can't install a different bare-metal OS on Oxide servers, or at least not without porting all the initialization work from illumos — but certainly it's nice to not be affected by any of these UEFI vulnerabilities.
tuxes

I'm not sure if that'd help. Even if the Linux kernel was willing to take on the responsibility of platform initialisation, the image would likely be old because flashing an image like that is scary, since if it goes wrong, then recovery might involve attaching an external flasher.

If your firmware is broken, you can't just plug in a USB drive and hope to boot that if it's your firmware that does platform initialisation and reads the USB drive. (Though some motherboards do have USB-recovery for writing firmware, e.g. Gigabyte Q-Flash Plus).

Firmware doesn't have to be terrible though. On x86, I use a lightweight UEFI implementation written in Rust: https://github.com/ArthurHeymans/CrabEFI and with Coreboot's vboot that allows me to A/B deploy the CrabEFI images.
- intelfx
  
  On x86, I use a lightweight UEFI implementation written in Rust: https://github.com/ArthurHeymans/CrabEFI and with Coreboot's vboot that allows me to A/B deploy the CrabEFI images.
  
  What hardware do you use that on?
  - tuxes
    
    PC Engines APU2 (router), CWWK ADLN NAS (NAS), and WIP on my gigabyte motherboard for my desktop.
    
    My laptop (t480s) has support but I've not yet got around to this.
    
    My Dell Optiplex 7070 doesn't, sadly.
- notgull
  
  LinuxBoot looks promising: https://www.linuxboot.org/
  - tuxes
    
    LinuxBoot is great. As the site says, it's a concept, and it's available for many platforms.
    
    https://github.com/u-root/u-root is an initrd builder designed for it, and makes it very easy.
    
    You still need platform initialisation (coreboot, uboot SPL, ...) to load the first kernel in your chain.
- proctrap
  
  To be fair no sane person connects management interfaces to the general internet, that was never a good idea.
  - xx
    
    The more interesting/useful attack vector is for local attacks where you already have physical access - e.g. Secure Boot bypasses and measured boot manipulation.