3 ms·

> 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 vulnerabilit

by Terr_ 5mo 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.

notepad0x90 5mo ago
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.
SahAssar 5mo ago
> 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?
- rwmj 5mo ago
  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 ...
  - bravetraveler 5mo ago
    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.
    - stinkbeetle 5mo ago
      I prefer 7 myself, but 0 is a perfectly good random number.
      - bravetraveler 5mo ago
        Ah, well, they disagreed and patched it. Now we get no say.
  - SahAssar 5mo ago
    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?
    - rwmj 5mo ago
      Confidential computing is a whole thing with a key in each processor and a chain of trust and a way to remotely attest that your software is running in a secure enclave. All the vendors do it differently (sadly) but it's very much a solved problem.
  - bri3d 5mo ago
    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.
- Terr_ 5mo ago
  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.
  - SahAssar 5mo ago
    > 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
    - lazide 5mo ago
      Sure, but the OEM is the definition of a ‘trusted environment’. They literally are assembling the equipment, if you can’t trust that, nothing else can be trusted from that point on anyway.
      - deleted 5mo ago
        [deleted]
    - deleted 5mo ago
      [deleted]
    - Terr_ 5mo ago
      I still can't figure out what problem you believe needs-fixing or what process you think needs to be explained. My most-charitable guesses are: A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised. B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com . C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy. Those are all interesting to contemplate, but they are at best "out of scope".
DANmode 5mo ago
> someone
- LearnYouALisp 5mo ago
  "Things break, Colonel!"
pseudohadamard 5mo ago
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.
Avamander 5mo ago
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.

by Terr_ 5mo ago

notepad0x90 5mo ago

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.

SahAssar 5mo ago

> 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?

rwmj 5mo ago
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 ...
- bravetraveler 5mo ago
  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.
  - stinkbeetle 5mo ago
    I prefer 7 myself, but 0 is a perfectly good random number.
    - bravetraveler 5mo ago
      Ah, well, they disagreed and patched it. Now we get no say.
- SahAssar 5mo ago
  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?
  - rwmj 5mo ago
    Confidential computing is a whole thing with a key in each processor and a chain of trust and a way to remotely attest that your software is running in a secure enclave. All the vendors do it differently (sadly) but it's very much a solved problem.
- bri3d 5mo ago
  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.
Terr_ 5mo ago
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.
- SahAssar 5mo ago
  > 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
  - lazide 5mo ago
    Sure, but the OEM is the definition of a ‘trusted environment’. They literally are assembling the equipment, if you can’t trust that, nothing else can be trusted from that point on anyway.
    - deleted 5mo ago
      [deleted]
  - deleted 5mo ago
    [deleted]
  - Terr_ 5mo ago
    I still can't figure out what problem you believe needs-fixing or what process you think needs to be explained. My most-charitable guesses are: A. You're asking what should be done if the manufacturer's auto-update server has already been completely compromised by hackers and remains compromised. B. [Implicitly rejected in last coment] You're asking how anybody can guarantee the very first install can be trusted even if someone has compromised drivers.amd.com . C. You're asking if the auto-update process can somehow trick a compromised daemon into overwriting itself with a legit copy. Those are all interesting to contemplate, but they are at best "out of scope".

DANmode 5mo ago

> someone

LearnYouALisp 5mo ago
"Things break, Colonel!"

pseudohadamard 5mo ago

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.

Avamander 5mo ago

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.