Debian 10.9 Released With FWUPD SBAT Support, Bug Fixes

[phoronix]

Phoronix: Debian 10.9 Released With FWUPD SBAT Support, Bug Fixes

While Debian 11.0 is brewing and currently under a hard freeze, Debian 10.9 is out this weekend as the latest stable update to Debian 10 "Buster"...

https://www.phoronix.com/scan.php?page=news_item&px=Debian-10.9-Released

[linuxgeex]

Since Michael didn't bother to spell out the acronym for the readers, SBAT is Secure Boot Advanced Targeting which is a methodology for requiring not only a signed version of a binary, but also a specific revision of that signed binary. This is basically a revocation system, which protects against signed file rollback attacks.

Imagine someone wants to attack your PC. They have access to your UEFI boot folder and they can modify various files, but they can only supply signed files or your PC won't boot and then you'd realise it was tampered with. They know one of your devices has a specific firmware vulnerability that was recently patched, and they want to exploit that vulnerability. It's an easy matter to replace the signed firmware with an older signed firmware and UEFI will happily accept it because it is signed. SBAT allows to require a version number for that file as well as being signed, which then prevents the firmware rollback attack.

[skeevy420]

Since Michael didn't bother to spell out the acronym for the readers, SBAT is Secure Boot Advanced Targeting which is a methodology for requiring not only a signed version of a binary, but also a specific revision of that signed binary. This is basically a revocation system, which protects against signed file rollback attacks.

Imagine someone wants to attack your PC. They have access to your UEFI boot folder and they can modify various files, but they can only supply signed files or your PC won't boot and then you'd realise it was tampered with. They know one of your devices has a specific firmware vulnerability that was recently patched, and they want to exploit that vulnerability. It's an easy matter to replace the signed firmware with an older signed firmware and UEFI will happily accept it because it is signed. SBAT allows to require a version number for that file as well as being signed, which then prevents the firmware rollback attack.

Geez. I'll try my luck with BlackArch off USB with a $5 wrench in reserve in case the encryption is too good.

[wswartzendruber]

Really looking forward to Debian 11 here.

[lucrus]

Really looking forward to Debian 11 here.

You can use it right now:

https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/

Still testing, but it works out of the box for most users. I'm using it with no issues at all.

[waxhead]

SImagine someone wants to attack your PC. They have access to your UEFI boot folder and they can modify various files, but they can only supply signed files or your PC won't boot and then you'd realise it was tampered with. They know one of your devices has a specific firmware vulnerability that was recently patched, and they want to exploit that vulnerability. It's an easy matter to replace the signed firmware with an older signed firmware and UEFI will happily accept it because it is signed. SBAT allows to require a version number for that file as well as being signed, which then prevents the firmware rollback attack.

I never looked to deep into the difference between the legacy BIOS and UEFI implementations. I still don't use UEFI at all. What I think is a general weakness with these systems is the use of FAT32 as a system partition. Do you know if it is possible (in Debian) to make a UEFI boot partition on multiple disks just as you would install GRUB on multiple disks to maintain redundancy in case a disk or two goes kebab?

[Paradigm Shifter]

I never looked to deep into the difference between the legacy BIOS and UEFI implementations. I still don't use UEFI at all. What I think is a general weakness with these systems is the use of FAT32 as a system partition. Do you know if it is possible (in Debian) to make a UEFI boot partition on multiple disks just as you would install GRUB on multiple disks to maintain redundancy in case a disk or two goes kebab?

Would running the EFI partition off a USB stick serve purpose? That would be easier to clone to keep a spare safe.

[linuxgeex]

I never looked to deep into the difference between the legacy BIOS and UEFI implementations. I still don't use UEFI at all. What I think is a general weakness with these systems is the use of FAT32 as a system partition. Do you know if it is possible (in Debian) to make a UEFI boot partition on multiple disks just as you would install GRUB on multiple disks to maintain redundancy in case a disk or two goes kebab?

You can RAID your boot volume and/or you can set up the UEFI to fall back to a secondary/tertiary boot volume in case of failure of the primary/seconary.

FAT is KISS and being KISS isn't a weak link. At boot time KISS is a strength. UEFI will happily use a fat16 boot volume and I always reformat it from fat32 to fat16 because I like it even more KISS. TBH I would be happy if UEFI instead moved to using a tar archive as the boot volume filesystem. Tar has no journalling, no fsck... it doesn't need it. It's set and forget, not a high-throughput transactional data store.

To have the benefits of ext4 for a UEFI boot volume you'd need an implementation of ext4 and fsck.ext4 in the mobo firmware. That would bloat the firmware to a point that someone could hide a complete operating system in the space of the ext4 driver if it were unused, thus leaving more room for advanced persistent threat malware written to the firmware. It also means a larger flash area which increases the BOM and elevates the cost of all motherboards. It also means that some OS developers will mistakenly assume it's more resilient, when actually it adds tons more structures which need to be in a consistent state. It also increases the minimum size of a boot volume, which then takes UEFI off the table as a boot option for smaller embedded products. Fat16 on the other hand only has a few kilobytes of required consistent structure. If a block dies on your ext4 boot volume it is more likely to fail than a fat16 boot volume, period. But if the volume is signed, a corrupt block will cause failover to a healthy volume regardless of the chosen filesystem. :-) So you may as well use the one with the lowest cost.

[linuxgeex]

phoronix what exactly about post #8 is leading to it being flagged as potential spam? All I did was talk about OS boot volume filesystem choice. No external links. No mention of anything that could be implied as commercial enticement. Time to reset your bayesian filter, it's obviously been poisoned to the point of being pathological.

[linuxgeex]

Would running the EFI partition off a USB stick serve purpose? That would be easier to clone to keep a spare safe.

It becomes an easy physical denial of service vector, not all firmwares are super reliable with detecting USB storage, and many thumb drives have unpredictable power-on delays ( they run consistency checks at power on and many have weak resources for that purpose ) which contribute to the likelihood of not being detected.

If you're just talking about a personal use PC where you can tolerate detection failure at boot time then yeah you can just reset and cross your fingers for the second startup.

If you care about uptime, ie your server is in a colo, you're really best off booting from PCIe SSDs, which is why all modern server boards are shipping with M.2 PCIe sockets. If it has 2 slots, put a different brand in each slot to mitigate the risk of simultaneous failure due to identical firmware bugs. Same thing if you have a RAID1 boot volume across 2 SAS/SATA SSDs - pick two different brands for the boot RAID pair.