new vulnerability in your motherboard lasts forever

wanna learn how computers work? learn to code at lowlevel.academy/

Jokes on you my motherboard is so old it predates this problem

Ok i guess i will just carve a new rock myself and hope no one will hack it

TempleOS affected :(

> Makes UEFI to solve security exploits in BIOS > Look inside > Exactly the same exploits BIOS has, but more flexible what did they mean by this?

Since I am 73 years old I have seen a lot of computer history. We know that over the years computers have become a lot more powerful, and have a lot more features, a lot more memory and a lot more storage. This has resulted in software of all types becoming a lot larger and a lot more complex. The result is that now nearly all software has unknown and undiscovered vulnerabilities. It is now impossible to eliminate all vulnerabilities. All that can be done is a lot of testing to discover the latest vulnerability.

Let's call it what it is: a successful NSA supply chain attack.

As soon as TPM was mentioned, I knew this was not a bug or mistake. This is a backdoor.

The fact that we keep inventing negative rings is also a problem. Everything old is new again. Hardware from the 80s used to have a hardware inhibit on floppy drives to prevent, at the hardware level, writing to a disk. Some of the early EEprom motherboards you had to move a jumper to allow the hardware to write to it. Perhaps this should be a new feature. I see that in the Pi4 and 5 you can update the "bios" from a linux command. Write protection at a jumper for this would be nice.

"Name the vendor of your motherboard's firmware" AMI. I haven't seen a computer sold with Phoenix BIOS as the firmware vendor in like 10 years.

When the title said the vulnerability lasts forever i thought you meant it was a hardware bug. Got me scared for a sec.

Feature not a bug. Say hello to NSA.

As a firmware developer: UEFI needs to go away. All vendors use basically the same stuff under the hood: EDK2 and FSP (Firmware Support Package). Problem is that EDK2's codebase is not only atrocious, people (or companies) usually work on their own forks and don't contribute it to upstream. Vendors like AMI, Phoenix or InsydeH2O use EDK2 versions that are several years out-of-date (last time I checked, from ~2018). That's why you see so many vulnerabilities in UEFI recently. Vendors basing their products on several-years-old releases, adding their own EFI drivers/apps (yes, EDK2 is basically an operating system that starts your operating system) and ship it to OEMs, who then ship it to users. So to fix the vulnerability vendor has to re-base their code on newer release (or patch it by hand), ship frameworks to OEMs, OEMs need to re-base their configuration on new version of frameworks (GPIO etc) and ship it to users, who need to go trough process of updating it (and we know how many people simply... don't). That's why opensource firmware is important, and should be more popular. Such as coreboot, u-boot and so on. As for this exploit, it likely won't "last forever". Most consumer motherboards use fTPM solutions (like Intel's PTT), which gets wiped on CPU swap (assuming the desktop) - same with SMMSTORE (NVRAM) or CMOS. On laptops however it would be a lot more tricky, but vendor can choose to wipe SMMSTORE on update, as well as TPM (though it would anger quite a few users who would need to find bitlocker recovery keys and whatnot).

Isn't it fascinating how all of this newfangled stuff has these ultra super secure "new" features that we later find have convenient oversights on that secure feature that allow someone in the know complete access to a device?

Never trusted TPM.

It's possible to write code that's literally proven formally to not have bugs like this, and it's wild to me that manufacturers don't do it. This UEFI code is the perfect candidate for formal verification. No future remediation path for bugs, universally appears in every product your company sells, and the cost doesn't even change much, since you're already hiring the kind of specialist firms that can do formal software verification. A no-brainer decision for motherboard manufacturers.

You forgot the part where it stays forever. It has to persist somewhere, either in the NVRAM or flash, so erasing both of those would remove the compromised code

The way Ed's face lights up every time he gets to say "low level" is the kind of passion I aspire to have for something

This was predicted when EFI was first rolled out. EFI is way too complex with not enough eyes on it, and EFI (+ TPM) has always looked like a US gov project. It did not actually solve any problems, unless you problem was how to compromise all machines in perpetuity.

No wonder Microsoft was pushing TPMs so hard with W11 /s