Hacker News Reader

Comment by jameshart | Hacker News Reader

Right - people who are upset that their motherboard can just drop arbitrary executables into their OS ZOMG would do well to consider the fact that their motherboard is literally handling executing their OS and managing all input and output.

The issue here is not motherboard can execute arbitrary code. Motherboards are trusted hardware. You pass all your keystrokes, network traffic and memory transfers over it.

The issue is motherboard uses its trusted status to run software that performs raw HTTP downloads for firmware. Which is probably bad but might alternatively just be futureproofing to avoid having to deal with expiring certs.

View on HN

Certificates do not have to expire. This is all firmware handling 101, you put a public key in the software update function, and the updater checks any alleged update against that key, no dates involved.

Actually, the OpenBSD people came up with "signify" which handles this more elegantly.

FTP is still advertised for download of this OS, but any tampering or otherwise corrupted files will not pass a signature test when signify is invoked.

The keys are rotated for every release, the next expected key is always included in the current OpenBSD release.

This system would be safe to fetch sensitive content over cleartext http.

EDIT: Here is a paper on signify:

https://www.openbsd.org/papers/bsdcan-signify.html

Debian does that since forever. Release file also contains

    Date: Wed, 31 May 2023 14:13:10 UTC
    Valid-Until: Wed, 07 Jun 2023 14:13:10 UTC

which allows spotting any tries of "downgrading" repository to previous version with potentially insecure packages

Of course, you still have to get current time somehow but I guess once RTC is set the device can assume the changes in time won't be huge and just use any kind of https source for that.

Neat, but only really relevant for rolling updates. This feature is a one-shot installer.

Right. But if you’re trying to establish an HTTPS connection to some server then that server’s cert is signed by some trusted root and THAT cert expires.

Which is why it might be more future proof to embed your own non expiring cert and use an out-of-band signature verification for firmware rather than relying on being able to establish an HTTPS connection forever.

At that point just use http + sigs.

If you have working signature infrastructure you don't need encryption. There is some danger, attacker can see what you are getting, but that's far lower than "the update broke"

Yes, that is what you should do. The problem is that they don't do that.

No harm in also running HTTPS on top of that as you can renew the TLS certificate without issue.

Doesn’t it do that with the firmware itself, i.e. verify that the firmware was signed by the manufacturer before updating?

So the HTTP request leaks information about the update and could be MITM, but the result could at best be an older version? (Which could be a known exploitable one!)

If the description is to be believed, then no, they don't do that.

But certificates expire for a reason, don't they? The idea is that with enough time, the key could be cracked.

That isn’t why certs expire. If a hacker could crack the key in some time that is longer than the expiry but short enough to be a threat, they could instead just spend that time cracking the signing key that verifies the cert signature… then, the hacker could generate as many trusted certs as they want for for any domain.

That's exactly why SHA1 was deprecated in TLS certs.

https://security.googleblog.com/2015/12/an-update-on-sha-1-c...

Even OCSP was affected: https://cabforum.org/2022/01/26/ballot-sc53-sunset-for-sha-1...

I wasn't trying to say that brute force wasn't a risk, just that it wasn't why certainly expire

The more pressing reason they expire for web sites is that site ownership can change and you don't want someone else having an infinite lifetime cert for a domain you just bought.

It's also useful to issue short lived certs and use the expiry date to handle revocation rather than maintaining a CRL.

Or, the private key could leak.

Or, the cert could have been issued by an authority which issued the cert despite compliance problems.

Web PKI is different than code signing, but if you look at the discussions within the CAB forum, there are very good reasons to limit certificate lifetime.

No.

The reason certificates expire is because historically the quality of the generators was known to be poor. NotAfter ensures that a new certificate is created with a better generator every now and then. Today that is not really a problem.

Public CAs are not very secure as NSA proved and I am not sure why there is no better alternative yet.

The reason is money. Sweet, delicious money

Indeed they would be well to but they won't be considering shit beyond a room temp IQ they just wanna play their gaymz

Don’t attribute to malice that which can be adequately explained by stupidity.

When it comes to corporations, don't attribute to stupidity that which can be adequately explained by greed. This could easily be avoided by having proper security engineering, but that costs money! They're only about a decade late to the whole post-Snowden "maybe we shouldn't trust unverified code delivered over interceptable cleartext channels" explosion.

This motherboard security stuff should get Linus tech tips level attention and absolutely roast them to the point of a reform

That is a cute quote, but people still need to be held accountable for compromising the ability of millions of devices to update firmware securely. Stupidity or malice, the end result is the same. Having said that, hopefully someone will investigate whether or not there was ill intent.

Any sufficiently advanced malice is indistinguishable from incompetence.

Reply on news.ycombinator.com