Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The RCE that AMD wouldn't fix

mrbruh.com

Post reply on HN
Print view View original

71–80 of 131 posts

Re: The RCE that AMD wouldn't fix

#71

Post by notepad0x90 »

Terr_ wrote: post #48

> 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 s…

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.

Re: The RCE that AMD wouldn't fix

#72

Post by tptacek »

zulln wrote: post #56
gruez wrote: post #52

Earlier quoted context omitted.

>Why would anyone ever exclude true mitm? Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.

Excluding SE is to make sure people do not spam customer support and launch annoying phishing campaigns. None of that is applicable for local software running on your own computer.

No, excluding SE is to make sure the bounty program is incentivizing things that inform the product security team. Social engineering is a corpsec function; they're not even the same teams.

Re: The RCE that AMD wouldn't fix

#73

Post by voakbasda »

RachelF wrote: post #63
nickdothutton wrote: post #27

AMD's inability to make good software has been a recurring problem for decades. Many years ago I had some success with their optimising compiler, but everything else I've touched was bad. A real pity.

Yes, their software is terrible across CPUs and GPUs, and continues to be. So many trivial bugs just never fixed. It has literally cost them a Trillion dollars in market cap - Nvidia's CUDA is a big reason they're so much bigger than AMD.

And that’s saying something, because the CUDA stack is a PITA.

Re: The RCE that AMD wouldn't fix

#74

Post by cute_boi »

nickdothutton wrote: post #27

AMD's inability to make good software has been a recurring problem for decades. Many years ago I had some success with their optimising compiler, but everything else I've touched was bad. A real pity.

AMD somehow got success, but their company culture and pay is shit. They expect PHD level experience but expect pay like peanuts....

Re: The RCE that AMD wouldn't fix

#75

Post by SahAssar »

Terr_ wrote: post #48

> 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 s…

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

Re: The RCE that AMD wouldn't fix

#76

Post by rwmj »

SahAssar wrote: post #75
Terr_ wrote: post #48

> 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 s…

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

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

Re: The RCE that AMD wouldn't fix

#77

Post by bravetraveler »

rwmj wrote: post #76
SahAssar wrote: post #75

Earlier quoted context omitted.

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

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

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.

Re: The RCE that AMD wouldn't fix

#78

Post by SahAssar »

rwmj wrote: post #76
SahAssar wrote: post #75

Earlier quoted context omitted.

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

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

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?

Re: The RCE that AMD wouldn't fix

#79

Post by DANmode »

Terr_ wrote: post #48

> 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 s…

> someone

Re: The RCE that AMD wouldn't fix

#80

Post by odyssey7 »

tptacek wrote: post #5
odyssey7 wrote: post #4

Earlier quoted context omitted.

What hair is this splitting? The issue was that AMD allowed a known and serious security vulnerability to exist within their customers’ systems, for months, and acted with a lack of candor while doing so.

It's not hair-splitting; it's central to the idea of a bug bounty. Too many people have weird ideas about what bug bounties are for.

Okay, fair. I was thinking mostly about the high-impact issue of preserving the security vulnerability and how an essential vendor was not being candid, but you are also right to note how AMD was avoiding its responsibilities to the individual researcher himself.
Post reply on HN