AINEWS
AMD's AutoUpdate Trusted the Network. The Network Can Be Adversarial.
A bug bounty that excluded man in the middle attacks missed an unauthenticated RCE in a privileged updater. The catch 22 in the fix is the part worth reading.
A bug bounty that excluded man in the middle attacks missed an unauthenticated RCE in a privileged updater. The catch 22 in the fix is the part worth reading.
AMD's AutoUpdate utility asked a network for code, accepted whatever came back, and ran it. The application performed no certificate check, no signature check, and no second look at what it had just downloaded. The download itself traveled in cleartext HTTP, pulled from a URL the updater read out of an XML manifest stored locally. A network adversary in the right position could swap that response for a payload of their own, and the updater would execute it (The RCE that AMD wouldn't fix).
That much is mechanical. The harder question is how a vulnerability this direct, an unauthenticated remote code execution chain running in a privileged updater on millions of machines, spent 124 days sitting in a disclosure queue after being reported. The answer, on the researcher's account, is that the bug bounty program that received the report had written man-in-the-middle attacks out of its scope, and the report was closed before a patch was ever discussed.
The updater matters because of what it runs as. AutoUpdate-style utilities typically operate with elevated rights, often as SYSTEM on Windows, because their job is to install and replace system-level AMD software. A network response that reaches that process is not a sandboxed download. It is host-level code execution. The security of every other process on that machine collapses to whether the response can be trusted. In AMD's case, the updater's own design said it could not be: an HTTP URL, no transport security, and no signature verification on the binary that followed.
The researcher submitted the chain to AMD's Intigriti-hosted bug bounty. The first response, on the researcher's account, came back as out of scope. MITM scenarios were excluded from the bounty rules, and the closed report did not commit AMD to a fix. The researcher then published a technical write-up. AMD's product security incident response team (PSIRT) contacted the researcher after publication, requested the post be taken down pending an official response, and reopened the review. The post came down during the review window. From initial disclosure to that point, 124 days had passed. The industry-standard coordinated disclosure window is 90 days. AMD's request for a longer review cited multiple affected optional tools and the time required for customer review (The RCE that AMD wouldn't fix).
AMD committed to issuing a CVE, crediting the researcher, and shipping a fix. The fix, when it came, removed the bundled auto-updater from the AMD installer entirely and moved update communications to HTTPS at the application layer. That is a substantive response to a real vulnerability. It is also a response that arrived only after the report had been made public, and only after a researcher had agreed to remove their own work product from the internet while the underlying exposure for users remained.
The catch-22 sits underneath. The patch that closed the RCE required the auto-updater to be functional. The auto-updater, separately, was reportedly broken by an unrelated redirect bug: ati.com resolving to drivers.amd.com in a way the updater could not follow. So the very mechanism the vulnerability exploited was also the mechanism the fix depended on. Until the redirect issue was resolved, the RCE fix could not be delivered through the channel the RCE had used. A user who wanted to be safe in the meantime had no updater-driven path to safety. The researcher's practical advice was to uninstall the bundled AMD software entirely and reinstall current versions directly from AMD's website (The RCE that AMD wouldn't fix).
The structural question is what scope rule would have caught this the first time. "MITM is out of scope" is a reasonable default for some classes of bug. It is the wrong default for a privileged auto-updater that fetches and executes binaries over the network. In that case, network-position attacks are not a theoretical threat model. They are the threat model. A scope rule that excludes MITM from a software component whose entire job is to consume network responses and run them as code is a scope rule that has been written to describe a different kind of product. AMD, the researcher, and the bug bounty platform can each argue about who should have recognized that first. The next case like this will not be argued about in the abstract. It will be argued about under the same rule, unless the rule is changed.
AMD's PSIRT is reviewing. The researcher is cooperating with that review. No CVE number, no AMD advisory, and no independent confirmation of current AutoUpdate behavior is cited here beyond the researcher's account, so the picture of what is fixed and what is not in shipped binaries should be treated as work in progress rather than settled fact. The industry takeaway does not depend on how AMD's patch lands. Any vendor whose updater fetches code over a network it does not control, and runs what arrives, has the same shape of problem. The default scope rule for those products needs to assume an adversarial network, because that is the only assumption the updater is making anyway.