As far as I read and understood the context of this security issue I didn’t find any evidence that PureBoot, coreboot, SeaBIOS are affected.
Am I right?
1 Like
I believe so, but we should refer to an expert. This article was also mentioned in “All Around Qubes” in the Qubes OS forum.
I think the article implies that they didn’t test such niche environments. It doesn’t mean that they are safe. To be sure, see whether they support custom logos at all, then inspect the image parsing code for quality / defensiveness against malformed data.
2 Likes
coreboot/SeaBIOS and PureBoot for Librem devices are not affected.
In a sentence, this vulnerability places a malicious logo on the EFI System Partition that UEFI firmware loads early in the boot process, so a compromise at that point can subvert UEFI Secure Boot.
Our PureBoot images do not have a bootsplash. Further, PureBoot (non-Basic mode) checks the signature on the contents of /boot before booting, so the attack surface for malicious tampering is limited to PureBoot’s signature information, the Linux filesystem driver, etc.
coreboot/SeaBIOS stores its bootsplash in ROM, but it doesn’t have Secure Boot or any anti-tampering guarantees anyway.
Neither of these does anything with an EFI system partition.
There are unofficial UEFI images for Librem devices - I don’t know yet if these are affected; I haven’t seen any information on whether EDK II is affected. However, if you are not using UEFI Secure Boot, then there is little to be gained from a vulnerability like this - an attacker that can alter your disk could also alter the kernel, initrd, bootloader, possibly firmware as well.
For the oldest Librem 13/15 devices that shipped with AMI firmware, that firmware may be affected, but again there is little to gain if UEFI Secure Boot isn’t being used. coreboot/SeaBIOS is available for those devices, PureBoot is available for 13v2+/15v3+.
3 Likes
How reassuring. It sounds like a great blog article for Purism to write about.
4 Likes