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

81–90 of 131 posts

Re: The RCE that AMD wouldn't fix

#81

Post by bri3d »

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

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.

Re: The RCE that AMD wouldn't fix

#82

Post by Terr_ »

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?

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.

Re: The RCE that AMD wouldn't fix

#84

Post by helterskelter »

Jesus after reading this I'm wondering if I want to switch my AMD Framework 13 Pro order to Intel, but the IME runs on Java if memory serves and it's not like they'll be any more secure.

I just hope we can get Libreboot working with Framework sometime.

Re: The RCE that AMD wouldn't fix

#85

Post by mnau »

hgoel wrote: post #60
OkayPhysicist wrote: post #37

AMD's utter incompetence when it comes to the software side of things is truly, truly baffling to me. It's not like you need a mountain of developers, a team or two on the right project would do wonders for their market share. For example: Implement the CUDA. CUDA's won, hands down, that toothpaste is solidly outside the tube. Luckily, to the outside observer CUDA is just an API, and API's aren't copyrightable. Liter…

HIP tries to be like this, almost API compatible with CUDA such that you just need to do find and replace. I think they even had a script to do this for you. But the issue remains that the actual support and debugging tools remain so atrocious that it doesn't help to combat the CUDA monopoly. They've further burned a lot of trust by never really delivering on their promises to do better unless you're a customer large…

HIP was such a self-own and clear demonstration of AMD software capabilities... well, the lack of software capabilities. HIP was hard-coded for one GPU architecture. CUDA did it right, it has a intermediate virtual assembly PTX and driver compiles it to whatever actual instruction set card actually uses.

Imagine a meeting where they signed off on that. So each developer will have to provide a different binary for each of our architectures? Yep. And once we release the new architecture, developer will have to recompile his program for the new architecture? Yep. Sounds good to me.

Re: The RCE that AMD wouldn't fix

#86

Post by tptacek »

odyssey7 wrote: post #80
tptacek wrote: post #5

Earlier quoted context omitted.

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.

I mean I think you think you're doing bank-shot snark here, but what you're really revealing is that your premises hinge on AMD trying to get out of paying a bounty simply to avoid paying it. Since we know up front that's not one of AMD's incentives, what does that do to your argument? It can't help.

Re: The RCE that AMD wouldn't fix

#87

Post by ethbr1 »

cute_boi wrote: post #74
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....

> expect PHD level experience but expect pay like peanuts

Thought this was par for the course in closer-to-hardware engineering.

Never understood why the objectively way harder jobs pay so much worse as an industry.

Re: The RCE that AMD wouldn't fix

#88

Post by rincebrain »

actionfromafar wrote: post #59
z3ratul163071 wrote: post #58

Earlier quoted context omitted.

likewise. i'm bewildered throughout the years. my suspicion is that it is the company culture: the hardware engineers are the real engineers. software is a triviality left for the lesser minds. the consequence is they mess up every product... everything they do needs software.

The argument I have read here on HN, is that CUDA is made for NVidia hardware, and the AMD hardware is not the best fit. Essentially it forces AMD to play by NVidias rules, exactly like how they were forced to follow Intel rules. (Ignore for a second that the API / ISA boundary is different.) But despite that, I also believe AMD would be better off just implementing CUDA.

They did, apparently, at one point pay someone to build that glue, and then threw it out and wouldn't let the author release it so he's been reimplementing it out of...spite? Burning desire? Unclear. [1]

I can't imagine the logic involved in "this is implemented, let's toss it in the dumpster" for that.

[1] - https://vosen.github.io/ZLUDA/blog/zludas-third-life/

Re: The RCE that AMD wouldn't fix

#89

Post by SahAssar »

Terr_ wrote: post #82
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?

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…

> 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

Re: The RCE that AMD wouldn't fix

#90

Post by lazide »

SahAssar wrote: post #89
Terr_ wrote: post #82

Earlier quoted context omitted.

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…

> 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

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.
Post reply on HN