If the autoupdater can't handle the redirection when grabbing the XML file, then it's a case of accidental safety by mistake that would prevent grabbing the plain http file.
So solves the MITM, but massive infection is still trivial if someone compromises the webserver.
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. Literally nothing is stopping AMD from hiring a relatively small team of developers to make AMD GPUs CUDA-compatible.
Don't bother to use Windows?
I started it with $100 - https://ko-fi.com/transactions/03df753c-09b0-4972-8e53-adf06...
Love this. I am frustrated by idiot software features everywhere, but am not triggered yet to punish them. AI automation is coming close however.
I am a diehard fanboy of their GPUs, and have been since they were still ATI but I had to finally purchase an nvidia GPU because of how bad AMDs software quality is.
My powerful 5700XT spent two years basically broken, because the default, driver provided fan curve locked the fan at 27%. For two years, I couldn't figure out why my GPU constantly crashed, because it was overheating, because the default fan curve prevented the GPU from keeping itself cool and it would eventually just give up.
That diagnoses was complicated by the fact that AMD GPUs just resetting is very common. There's a watchdog timer in Windows that resets parts of the GPU stack because Microsoft is traumatized by 60% of Windows Vista BSODs being caused by bad nvidia drivers. Apparently sometimes if you increase this watchdog timer, the GPU eventually finishes whatever was giving it trouble.
But I still love AMD, and the ryzen line is a great value in the mid range. So I bought another AMD CPU and am very happy with it. But it somehow included software and this specific auto updater utility. Which I don't need, since I don't want to update the drivers for a GPU that I shouldn't be using (maybe except some video encoding lift, but my GPU can do that too). But I could not figure out a way to kill or prevent this stupid little autoupdater utility which always steals focus, for no reason at all. It shouldn't even be popping up a CLI! Windows task scheduling is incredible and would do this without a problem, and give you all the infrastructure to notice this was happening!
Works great!
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.
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…
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 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
Given the way AMD has been treating this issue, I'm assuming they're just incompetent, though.
Same reason security programs exclude social engineering, even though that's a pretty common way for companies to get pwned.
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.
That’s my take.
After being interrupted multiple times by an annoying console window that would pop up periodically on my new gaming PC, I managed to track the offending executable down to AMD’s AutoUpdate software.
In my frustration, I decided to punish this software by decompiling it to figure out how it worked, and accidentally discovered a trivial Remote Code Execution (RCE) vulnerability in the process.
The first thing I found is that they store their update URL in the program’s app.config. Although it’s a little odd that they use their “Develpment” URL in production, it uses HTTPS, so it’s perfectly safe.

The real problem starts when you open up this .xml URL in your web browser, and realise that all the executable download URLs are using HTTP.

This means that a malicious attacker on your network, or a nation-state that has access to your ISP, can easily perform a MITM attack and replace the network response with any malicious executable of their choosing.
I was hoping that AMD perhaps had some form of certificate validation to ensure that it could not download and run any unsigned executables. However, a quick look into the decompiled code revealed that the AutoUpdate software does no such validation and immediately executes the downloaded file.

After finding this, I thought it would be worth reporting to AMD, as it seemed pretty severe.
Unfortunately, the terms of service of their bug bounty program state that man-in-the-middle attacks are out of scope, and it was closed as such.

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.
I am writing from AMD PSIRT. We are still conducting an internal review of your report. Please note that even if Intigriti has rejected the submission as out of scope for the bounty program, we are still happy to review the details to determine whether there may be any potential validity.
Note: Intigriti is the third-party bug bounty platform AMD uses for initial triage, while PSIRT (Product Security Incident Response Team) is AMD’s internal security team.
Additionally, they requested I take down the blog post until they patched the issue.
We were informed that a blog post discussing this issue has already been published, which does not appear to be in accordance with the program’s terms. Could you please take the post down and wait for us to complete our review and provide an official response?
I agreed to do so, which, in hindsight, I believe was the wrong choice to make.
The report was marked out of scope because it is not eligible for a bounty under our current program guidelines, as it affects optional tools and relies on a MITM attack scenario.
After further internal review, we've decided to:
- Issue a CVE for this vulnerability
- Implement a fix
- Provide you with security researcher recognition
After agreeing to take down my blog until the vulnerability was patched, they followed up by detailing that they would not be paying me because it’s an optional tool and requires MITM, but instead they would be issuing a CVE for this and giving me credit.
What disclosure timeline you intend to follow?
e.g 90 + 30 days
I asked them what disclosure period they were planning to follow for this issue. The industry standard is 90 days, and after looking at other researchers’ write-ups, I can confirm the majority of AMD’s vulnerabilities were addressed within 90 days.
Hi @mrbruh, We will likely need a longer embargo, as additional tools beyond Ryzen Master appear to be impacted and will need releases. I’ll keep you updated as we learn more.
So in summary, this is the current state of the disclosure:
s to an http URL in their hosted XML file (so it should be relatively easy to fix).I ended up waiting an additional 69 days, for a total of 87 days from disclosure until I reached out again.
I told them that I could not continue to wait an indefinite amount of time for them to fix this issue, and that I planned to publish my write-up again at 100 days after initial disclosure had passed.
AMD did not actively keep me updated, despite assuring me they would. They only told me what the fix for this vulnerability was a couple of days before the embargo ended (and only after I explicitly asked).
Multiple optional tools are affected by this. We are awaiting release on at least one of them. Moreover, our customers request additional time to review fixes once they are made available. So we request you to hold public disclosure to give additional time for customers.
They initially just asked for “more time”, without specifying a disclosure period, but two days later they agreed to end the embargo on June the 9th.
Hi @mrbruh, I have asked the engineering teams to expedite this so we can disclose it on June 9th. Will keep you updated.
I am planning to publish this updated write-up, a total of 124 days after initial disclosure.
124 days to get AMD to add an s to a couple of HTTP URLs!
I don’t think it even matters what patch AMD has cooked up to fix this issue.
According to a link posted in the Hacker News thread of my original post, the auto updater is completely broken due to a second, entirely unrelated reason.
They switched from hosting their list of software packages on ati.com to drivers.amd.com at some point.
Opening the XML URL in your web browser will automatically redirect you to the new domain. However, the AutoUpdater program cannot handle this redirection, causing it to crash or lock up.

In some weird twist of events, I guess this means that the vulnerability I found actually isn’t exploitable because the AutoUpdater doesn’t even reach that section of code before completely shitting the bed.
It also results in a kind of Catch-22: you need to update the updater to fix the vulnerability, but the updater won’t update until the redirection bug is fixed. Nice.

If you are an AMD user with their software installed, I highly suggest fully uninstalling everything, then grabbing the new versions from their website.
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:
Hi @mrbruh In Ryzen Master, the auto-updater functionality has been removed from the installer and moved to the application layer.
Within the application, all update communications are secured using HTTPS, and updates undergo signature verification.
I have since validated those claims. 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 far for the vulnerabilities I have reported to Google, ASUS, AMD, TP-Link, MSI (and more), have paid out a total of $0. The AMD vulnerability would have paid out ~10k USD if it was considered in scope.
If you found this article interesting or useful, you can buy me a coffee via my KoFi: https://ko-fi.com/mrbruhh
won't fix/out of scope