The RCE that AMD wouldn't fix

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

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

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

MITM where attacker needs to install their own CA certs on the victim's device -- sure, out of scope.

MITM because you used http instead of https and you don't have any other verified cryptographic signature on your data -- get tae fuck, fix it pronto.

Why would anyone ever exclude true mitm?

Various domain registrars have been compromised over and over again (often by children!), resulting in companies like Tesla and Cloudflare getting owned.

The reality is that any vaguely competent attacker can compromise a court clerk and just compel e.g. the .com registry to hand over whatever domain they want.

Although I suppose the aforementioned problem has significant implications beyond dns…

Out of scope does not necessarily mean out of impact. It is merely a question of how far a company wants to be responsible for the environment their software is run in. Most of the time that answer is "not much."

Out of scope in this case means "we don't wanna pay you"

But I use a Wi-Fi password, so my phone says it's secure!

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.

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

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

It's technically possible (though I don't know if they actually do this) that they're not referring to a signature check in the download part, but are verifying the code signing signature of the executable downloaded. You'd only notice the CRC if you were looking at the downloaded content, but if the updater refuses to launch an executable that isn't signed by AMD's cert then they would be fine.

Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.

Especially because if they had read about or studied this problem they would find tons of prior art where CRC32 was considered not secure for solving the problem. CRC32 solves a different problem -- how do you verify that the data that was received is identical to the data that was sent. It makes no guarantees about who is sending the data, which is the real problem signatures solve.

   It's fairly trivial, but still significantly harder than computing a single CRC.

    Noise is not the only thing they should be protecting against.

They should have done base64 encryption before the crc32. noobs

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.

How do we know the incentive is to pay out bounties? And how do we know that doesn't change on the whims of the management chain?

We don't "know" anything unless we are at that company in particular and part of the management conversations. We at best can theorize based on incentives, but that's assuming companies and people are logical, which is a large assumption. I could easily see someone in the midst of layoffs and reduction of overhead initiatives thinking that the solution is to convince everyone you do payouts, but actually minimize payouts, which you could do by creatively using scopes.

They wanted to keep it quiet. As if they did not mind if it was exploited by those with access to international network links.

The original post [1] now includes an update:

  UPDATE! Within a day of this blowing up on Hacker News, AMD reached back 
  out to me and said they would be looking into the matter after all.

[1] https://mrbruh.com/amd2/

I got so mad at plex/jellyfin's crap I vibe coded an entire entertainment system out of spite.

Works great!

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

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.

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 enough to get personalized attention from their engineers.

This ends up being a double whammy because not only are you pushing away smaller businesses, you're also pushing away single developers that go on to influence purchasing/development decisions.

You'd imagine they'd just reuse and verify the Authenticode signature the very least.

They added CRC32 lol

Glowing!

Drivers got better after ATI merged/got bought by AMD, but ATI has a loooooong legacy of terrible drivers in Windows.

The funny thing is, in Linux, the drivers are pretty great as far as I can tell. It's not like there aren't bugs, probably, but mostly everything "just works". You can't depend on FSR in Linux, for example - Doom Eternal just goes blank if you turn it on. I can live without it, though, and everything else seems fine, including performance.

Nvidia linux drivers make me quite upset - they're fine once you finally get them working, but you approach Nvidia driver updates with extreme caution in Linux

There is something wrong with the internal fan curve on my old rx580 as well. I ended up writing a controller to manually set the fan speed via the /sys interface.

I still need to figure out why the internal curve is not working, but have not gotten around to it because I like my controller so much. The novel bit is that as I was writing it I had an epiphany "Why a curve? What we really want is to close the loop. Set an ideal temperature and figure out the fan speed to maintain it" So my controller has a cute little PID loop to do just that. realistically it never works as I imagined. At idle the temp is lower then the set point at the slowest fan speed and at load the full speed fan keeps it ~ 10C higher than the set point(perhaps this means my set point should be higher?). but sometimes I get that goldilocks midrange load and it works great.

It doesn't smell like a state actor to me, just gross negligence. Brushing up on the Reddit comment we wrote, the MITM isn't exploitable by default, since the client will error out at the 301 redirect and leave an obvious black window on the user's desktop. Exploiting a user would require replacing the 301 redirect with a direct download, which requires the same amount of effort whether the default disclosure was broken or not.

Now if they could've started shipping a modified AMD auto update that followed redirects, that would allow them to pwn users of the updated program. But it would do nothing to people who had installed older versions, up to the version the author installed (which left a black window open indicating the downloads never completed)...

I say the same when I dealt with Amazon's website, and to a smaller extent eBay.com. Don't forget Facebook Marketplace.

A bug in a nonfunctional autoupdater. Big state actors. Got it.

They keep choosing to work whitehat instead of blackhat, which is all AMD ever wanted.

Yeah, it's annoying. But it's been captured by popular culture as meaning a blatant lie - one where the liar knows the truth is or was available/obvious. A "don't piss on my leg and tell me it's raining" lie.

Or, alternatively, and especially in gender relations, any lie intended to manipulate or demean another person. As opposed to lying to protect yourself, to swindle somebody, or some other reason. This is closer to the original idea, but still not there.