←back to thread

253 points pabs3 | 2 comments | | HN request time: 0s | source
Show context
mkj ◴[] No.44602124[source]
It's not just Linux - certificates to sign Windows are also affected in 2026.

https://support.microsoft.com/en-us/topic/windows-secure-boo...

https://techcommunity.microsoft.com/blog/windows-itpro-blog/...

Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful!

Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).

replies(5): >>44602428 #>>44602690 #>>44602733 #>>44602895 #>>44617707 #
jeroenhd ◴[] No.44602733[source]
The mistake was not to put an expiry date on the certificates, but to trust hardware vendors to do even basic firmware maintenance after motherboards and laptops leave the warehouse.

In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.

In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.

replies(5): >>44603271 #>>44603290 #>>44603448 #>>44603660 #>>44604239 #
RedShift1 ◴[] No.44603271[source]
Which to me leads me to a bigger problem, UEFI is trash, too complicated, too bloated, too hard to implement all the various bits and pieces.

In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.

replies(6): >>44603474 #>>44603658 #>>44603786 #>>44603793 #>>44604202 #>>44617759 #
jeroenhd ◴[] No.44604202[source]
UEFI standardizes the things vendors and operating system manufacturers were already doing anyway. Even in the BIOS days, firmware was doing PXE boot and things like modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.

You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement.

I'll take UEFI over BIOS any time if only because it finally solved dual booting.

replies(2): >>44604271 #>>44673176 #
1. xg15 ◴[] No.44604271[source]
> modifying Windows' memory to inject a binary at boot time to inject their drivers/crapware into clean installs.

Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS?

This stuff seems inches away from a supply chain attack.

replies(1): >>44616277 #
2. OptionOfT ◴[] No.44616277[source]
https://view.officeapps.live.com/op/view.aspx?src=https%3A%2...

It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...