HN Reader

One good thing we can say about Linux bundling all the drivers is that it obviates the need to run almost all of this type of low quality (if not outright spyware) driver management software. They are especially problematic because they can't be sandboxed easily like most other proprietary crap.

For whatever reason, distro maintainers working for free seem a lot more competent with security than billion dollar hardware vendors

This is why I've blocked all HTTP traffic outgoing from my machines.

A lot of people have brought this up over the years:

https://www.reddit.com/r/AMDHelp/comments/ysqvsv/amd_autoupd...

(I'm fairly sure I have even mentioned AMD doing this on HN in the past.)

AMD is also not the only one. Gigabyte, ASUS, many other autoupdaters and installers fail without HTTP access. I couldn't even set up my HomePod without allowing it to fetch HTTP resources.

From my own perspective allowing unencrypted outgoing HTTP is a clear indication of problematic software. Even unencrypted (but maybe signed) CDN connections are at minimum a privacy leak. Potentially it's even a way for a MITM to exploit the HTTP stack, some content parser or the application's own handling. TLS stacks are a significantly harder target in comparison.

This is super bad right? Like anybody who has this running will be vulnerable to a super basic HTTP redirect -> installer running on their machine attack, right? And on top of that it's for something that is likely installed on _so many_ machines, right?

I don't think I've ever seen something this exploitable that is so prevalent. Like couldn't you just sit in an airport and open up a wifi hotspot and almost immediately own anyone with ATI graphics?

So compromising one DNS lookup is sufficient, ex:

1. Home router compromised, DHCP/DNS settings changed.

2. Report a wrong (malicious) IP for ww2.ati.com.

3. For HTTP traffic, it snoops and looks for opportunities to inject a malicious binary.

4. HTTPS traffic is passed through unchanged.

__________

If anyone still has their home-router using the default admin password, consider this a little wake-up call: Even if your new password is on a sticky-note, that's still a measurable improvement.

The risks continue, though:

* If the victim's router settings are safe, an attacker on the LAN may use DHCP spoofing to trick the target into using a different DNS server.

* The attacker can set up an alternate network they control, and trick the user into connecting, like for a real coffee shop, or even a vague "Free Wifi."

FTA: “Therefore I will have to close the report as out of scope”

and “05/02/2026 - Report Closed as wont fix/out of scope”

I think it’s a bit early to say “won’t fix”. AMD only said that it was out of scope for the channel used to report it (I don’t know what that was, but it likely is a bug bounty program) and it’s one day after the issue was reported to them.

Wow, this is an extremely serious vulnerability. People writing it off because it requires MitM. There's always a MitM, the internet is basically a MitM.

If this is as described, it's a pretty major failure of security-vulnerability report triage, and rises to the level where security departments at major corporations will be having meetings about whether they want to ban AMD hardware from their organizations entirely, or only ban the AMD update application. If this had gone the "brand name and a scored CVE" route, it would probably have gotten a news cycle. It might still get a news cycle.

The threat model here is that compromised or malicious wifi hotspots (and ISPs) exist that will monitor all unencrypted traffic, look for anything being downloaded that's an executable, and inject malware into it. That would compromise a machine that ran this updater even if the malware wasn't specifically looking for this AMD driver vulnerability, and would have already compromised a lot of laptops in the past.

They're not considering it not to be a vulnerability. They're simply saying it's outside the scope of their bug bounty program.

Can anyone rationalize this decision? Sure technically this is outside the stated scope however the severity of this vulnerability is immediately obvious, which should trigger some alarm bells that the scope needs to be reconsidered.

If they lose just one customer over this they're losing more than the minimum $500 bounty. They also signal to the world that they care more about some scope document than actually improving security, discouraging future hackers from engaging with their program.

This would be a high severity vulnerability so even paying out $500 for a low severity would be a bit of a disgrace.

What's the business case for screwing someone out of a bounty on a technicality?

AMD AutoUpdate terminal always pops up at midnight for me and then requires me to dismiss it. I've been meaning to uninstall this but always forget about it the next morning.

Now I have good reason to block it entirely and go back to manual updates

While I don't like that the executable's update URL is using just plain HTTP, AMD does explicitly state that in their program that attacks requiring man-in-the-middle or physical access is out-of-scope.

Whether you agree with whether this rule should be out-of-scope or not is a separate issue.

What I'm more curious about is the presence of both a Development and Production URL for their XML files, and their use of a Development URL in production. While like the author said, even though the URL is using TLS/SSL so it's "safe", I would be curious to know if the executable URLs are the same in both XML files, and if not, I would perform binary diffing between those two executables.

I imagine there might be some interesting differential there that might lead to a bug bounty. For example, maybe some developer debug tooling that is only present only in the development version but is not safe to use for production and could lead to exploitation, and since they seemed to use the Development URL in production for some reason...

How the hell is it possible that they're still using the ATI domain and HTTP 2026? They acquired ATI 20 fucking years ago.

It really makes you wonder what level of dysfunction is actually possible inside a company. 30k employees and they can't get one of them to hook up certbot, and add an 's' to the software.

From the title, I thought this was going to be another one of those speculative execution information leakage bugs that are basically impossible to fix, but something this simple and easily fixable -- it's discouraging. Hopefully this decision is reversed. Also "Thank you for hacking our product" seems a bit unprofessional for someone engaging in responsible disclosure for a major security issue with your product.

Meta: somewhat surprised that they're still using ati.com. ATI was acquired back in 2006:

* https://en.wikipedia.org/wiki/ATI_Technologies

Why even bother with WONTFIX? Turning on an nginx LetsEncrypt in front of it would have taken as long.

What is the root cause of this? It is said that AMD is hardware company and neglects software - but recently they issued lots of declarations of becoming software firs now.

Marking this as a WONTFIX should have gotten somebody fired at AMD. I find it hard to believe that at least one of their VPs doesn't frequent this site.

I don't normally call for people to get fired from their jobs, but this is so disgusting to anyone who takes even a modicum of pride in their contribution to society.

Surely, someone gets fired for dismissing a legitimate, easily exploited RCE using a simple plaintext HTTP MITM attack as a WONTFIX... Right???

Bugdoors, bugdoors everywhere..

The fact that they refuse to fix is the sketchiest part, and also they should be held accountable for things like this IMO

Many people don't worry about connecting to random wifi anymore, but users of AMD still have to

This is unfortunate news but I'm not even surprised that they don't seem to care. Nice writeup.

It's not directly an RCE unto itself, it requires something else. A compromised DNS on the network, e.g. So no surprise they ignored it.

Also, if AMD is getting overwhelmed with security reports (a la curl), it's also not surprising. Particularly if people are using AI to turn bug bounties into income.

Lastly if it requires a compromised DNS server, someone would probably point out a much easier way to compromise the network rather than rely upon AMD driver installer.

Thanks for this, author.

No https:// and no cryptographic signature nor checksum that I can see. This makes it almost trivial for any nation-state to inject malware into targeted machines.

I removed AMD auto-update functionality from Windows boxen. (And I won't install anything similar on Linux.) And, besides, the Windows auto-update or check process hangs with a blank console window regularly.

Such trashy software ruins the OOBE of everything else. Small details attention zen philosophy and all that.

If this is true, it seems like a much more serious vulnerability than I was expecting when I clicked the link.

And it's obviously an oversight; there is no reason to intentionally opt for http over https in this situation.

Based on the policy (and my hat) I have to assume some business partner failed to maintain the 'ca-certificates' equivalent for Windows (or NTP) and was rewarded in their insane demand for plaintext.

So easy to fix, just... why? My kingdom for an 's'. One of these policies are not like the others. Consider certificates and signatures before categorically turning a blind eye to MitM, please: you "let them in", AMD. Wow.

Even though the software might have been written by AMD, I think there is at least one more party to blame.

Who has put that software on the PC in the first place?

Was it the manufacturer?

Or was it Microsoft via Windows?

>Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts

I love how they grouped man in the middle there

I was in the shop for new PC today and decided on 9950x3d but I don't know how I opened HN just before the checkout and now I am a happy owner of intel 14900!

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

    http://www2.ati.com/...

I'm blocking port 80 since forever so there's that.

But now ati.com is going straight into my unbound DNS server's blocklist.

> 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 am pretty sure, a nation state wanting to hack an individual's system has way more effective tools at their disposal.

Spooky, this is not exposure if using Linux?

Auto Update is EVERYTIME a RCE. When the software checks a signature, you just need the key. And the delivering enterprise have the key. EVERYTIME.

Don't understand why most people mean auto updating software would in any way create more security. It just creates more attack vectors for every software that has a auto updater.