Comment by Terr_
4 days ago
> Final update: A couple of days before the embargo ended (and after I wrote the majority of this blog post), AMD told me what their patch for this vulnerability is [...] Although it is true that they now fully use HTTPS, the claim about signature verification is untrue; they only perform a CRC-32 check on the downloaded executable, which is not cryptographically secure.
So solves the MITM, but massive infection is still trivial if someone compromises the webserver.
> someone compromises the webserver
Sure, but that's true for 99% of things. Unless you establish trust outside of the normal distribution channel how would you protect against this? What is your proposed channel that is not bootstrapped from HTTPS PKI?
What? The bootstrapping happened already! The official and correct AMD software already running on the computers. Preventing a human from falling for an impostor-website with malicious Download Now links is a separate problem.
The basics are straightforward: It'd be better if the current installation contains one (or more) public keys, and anything it downloads must validate as being signed by a corresponding private key. You don't need to do fancy things like global certs, discoverable keys, or revocation lists.
If today's installation doesn't have those checks and relies solely on HTTPS... well, that's unfortunate, but it's not like it poses a tricky dilemma! You simply use today's not-so-secure mechanism to install the new code which has more-secure behavior, and it closes the attacker's window of (easier) opportunity.
> The current installation shall already contain one (or more) public keys that it trusts for updates
The current installation was fetched via HTTPS, right? Either by you or in the factory.
Just saying the "bootstrapping already happened" does not make it not happen. It still needs to bootstrap trust from somewhere
6 replies →
AMD (and Intel and everyone else) processors already have an HSM inside for confidential computing so use that? I would hope the HSM isn't as badly implemented as this update mechanism, but then again ...
AMD Software Engineers giving AMD Stupid Gaming Accessory Software Engineers access to a signing system backed by PSP seems like a much worse outcome than trusting HTTPS, really. Like, there are definitely intelligent and secure ways to do this, but this one in particular is overkill with a huge blast radius when it is (invariably) done incorrectly.
Those have been broken again and again. Even if not, how do you distribute the public keys for it, how do you bootstrap that trust?
1 reply →
There was a time when RDRAND on Zen gave all zeroes, or something, so eh...
I'm happy enough with TLS introduced: knowing the server I'm reaching for updates is actually 'amd.com'. Signatures would be nice, sure, but I wouldn't consider them nearly as critical or useful until now. Before we get too caught up in signatures, however, I'd like to see their new/improved updater actually take precedence.
As things stand, I'm not sure key rotation would go well... the updater doesn't mind itself, apparently.
2 replies →
It's OK though, AMD is a US company so there's nothing to worry about. It's only when a Chinese company does the same thing that it's an evil CCP backdoor designed to destroy civilization.
what are the chances of them caring so little, but implementing a dedicated signing server, HSM,etc..? even if they sign it, it will probably be done on the same web server.
Wacom does the same CRC-32 BS in their updater.
I blocked HTTP connections from my local network years ago and you wouldn't believe how many driver installers and auto-updaters break. One should never trust a HW vendor's (auto-)update implementation.
> someone
"Things break, Colonel!"