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

61–70 of 131 posts

Re: The RCE that AMD wouldn't fix

#61

Post by Hizonner »

tptacek wrote: post #33
Hizonner wrote: post #13

Earlier quoted context omitted.

... which is why the rest of us should give them, and those who operate them, zero respect . Nobody but AMD gives a fuck about AMD's internal policies or motivations.

I have thought about AMD's security team and their practices once in the past 18 months, and it was this morning, reading this thread. I do not care about AMD or what you think about AMD. AMD has absolutely nothing to do with my point.

You commented on this very issue when it first came up 4 months ago. If I remembered that, so should you. I mean, I'm prepared to believe that you did not think on that occasion, if you want to confirm that's what you mean...

If you don't care about AMD, why are you white-knighting AMD and defending AMD's bad behavior?

But, hey, OK, let's not make it about AMD specifically. It doesn't matter what any company thinks the purpose of its program is, nor does it matter what scope any company unilaterally decides to set for its program. What the outside world is going to see is whether or not you ignore security bugs. Your weird arcane internal policies, justifcations, and "scopes" are irrelevant. And, although I don't honestly care much about "security researchers", you can't really expect them to keep track of your private set of scope rules either... assuming you even tried to tell them the rules in advance to begin with.

Re: The RCE that AMD wouldn't fix

#62

Post by asveikau »

> 124 days to get AMD to add an s to a couple of HTTP URLs!

I disagree that they should only add HTTPS and call it done. They should also add some kind of signing check before running the payload.

If anything I'd say HTTPS is optional if they do that part.

Re: The RCE that AMD wouldn't fix

#63

Post by RachelF »

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.

Re: The RCE that AMD wouldn't fix

#64

Post by 20k »

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…

AMD's entire software development strategy is insane. OpenCL was doing reasonably well, and then AMD have just fully dropped support for some reason. For the - albeit not huge - but actual cross platform API that people were using to develop for their GPUs. For a while, a few cross platform tools had OpenCL backends, but nobody has been able to get AMD to fix any of the damn bugs. In my testing, bug latency for even the most trivial but important bugfixes is often 4+ years, which is utterly mad. Some parts of their compute stack is so broken its clear that nobody has ever used it. There are exploitable privilege escalation vulnerabilities caused by threaded race conditions that are wontfix

They could support OpenCL 3.0. Nvidia do. AMD just chooses not to, even though they're the ones that desperately needs to support it most

Instead, we got ROCm which has been a disaster from start to end. It barely supports windows or consumer GPUs, for some reason. Its a buggy mess, for some reason. HIP/ROCm has worse performance than OpenCL, because they downgraded their compiler and stopped extracting read/write information on variables leading to a massive loss of parallelism and utilisation on their GPUs.. for some reason. Why? What are they doing? How is this so rubbish?

Literally ALL of this is WONTFIX, and I don't have a clue why. I've filed bugs, was part of their vanguard supporter program, have tried to reach out to AMD people to (gently) explain why good support is important. Or even just figure out what technology they're even intending to support for GPU development. Is ROCm deprecated? What should we be using on windows for GPU compute on consumer hardware AMD? For the love of god amd I want to make you money

As of 2026, the best cross platform cross vendor API for doing GPU compute is.. drumroll.. OpenCL 1.2. Vulkan is getting there, but its still missing a bunch of stuff. And this is literally AMDs direct fault at this point

Re: The RCE that AMD wouldn't fix

#65

Post by Bilal_io »

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.

Their pay is shit. I interviewed with them 3 years ago and they offered me peanuts I rejected their offer.

Re: The RCE that AMD wouldn't fix

#66

Post by tptacek »

Hizonner wrote: post #61
tptacek wrote: post #33

Earlier quoted context omitted.

I have thought about AMD's security team and their practices once in the past 18 months, and it was this morning, reading this thread. I do not care about AMD or what you think about AMD. AMD has absolutely nothing to do with my point.

You commented on this very issue when it first came up 4 months ago. If I remembered that, so should you. I mean, I'm prepared to believe that you did not think on that occasion, if you want to confirm that's what you mean... If you don't care about AMD, why are you white-knighting AMD and defending AMD's bad behavior? But, hey, OK, let's not make it about AMD specifically. It doesn't matter what any company thinks t…

Why do you think we're going to have a productive conversation after accusing me of "white-knighting" for AMD (and how does that even make sense? What's your mental model of why I would be doing that?)

My motivation here is very simple: I think people dunking on AMD's bounty program here mostly don't understand how bug bounties function. You apparently keep track of my comments on HN, so I think you know that's a beat I have here.

Re: The RCE that AMD wouldn't fix

#67

Post by tptacek »

tlb wrote: post #15

It's ridiculous to consider MITM attacks out of scope for taking over your computer. Also, there are probably ways to exploit this without a true MITM like DNS cache poisoning. But it's best to just assume the whole internet is MITMed.

It's not out of scope "for taking over your computer". It's out of scope for the specific goals of the bug bounty program. Bug bounties are (usually) about prioritizing internal engineering effort; they are to vulnerability remediation what market feedback is to feature/function decisions in the rest of the product.

Everyone's judging this by the standard of "how good a bug" this is. But that's not necessarily how a bug bounty should function. Important prior to frame this with: neither any individual bug bounty submission nor the sum of all valid submissions materially alters the security of a serious product, at least not on their own. The system they feed into (for instance: security engineers taking a validated bounty submission and then quickly auditing the entire tree for variants of the same bug) can move the dials. The bounty bugs themselves though are mostly a sideshow.

What's especially weird (you didn't say this, but the sentiment has popped up on all 3 threads about this story) is the idea that AMD would be trying to cover this up. Why would they care? They run a bug bounty program. They've accepted the premise that they have vulnerabilities.

(From earlier today, in add'n: https://news.ycombinator.com/item?id=48492908).

Re: The RCE that AMD wouldn't fix

#68

Post by ddtaylor »

asveikau wrote: post #62

> 124 days to get AMD to add an s to a couple of HTTP URLs! I disagree that they should only add HTTPS and call it done. They should also add some kind of signing check before running the payload. If anything I'd say HTTPS is optional if they do that part.

They added CRC32 lol

Re: The RCE that AMD wouldn't fix

#69

Post by ForOldHack »

Let this lesson be learned: "In my frustration, I decided to punish this software by decompiling it to figure out how it worked,"

Note to self: Never piss off a programmer, while he is gaming. To quote: "You're gonna die for that." -Duke Nukem.

Re: The RCE that AMD wouldn't fix

#70

Post by [deleted] »

AlotOfReading wrote: post #43
wat10000 wrote: post #35

Earlier quoted context omitted.

More specifically, it solves the problem of verifying that the data received was not accidentally corrupted somehow. Unlike cryptographic hashes, CRC32 does not do much to defend against deliberate, malicious modification. It's too easy to craft some different data that matches a given CRC32 value.

Computing a CRC is equivalent to attacking it. The checksum is the value that produces a certain fixed constant when appended to the data. This is why you'll often see checksums as the last field in a message. It allows for hardware to verify the entire message by checking if the CRC of the bytes equals that fixed constant without having to parse it.

[deleted]
Post reply on HN