The RCE that AMD wouldn't fix
A frustrated researcher reverse-engineered AMD's AutoUpdate software, uncovering a trivial Remote Code Execution (RCE) vulnerability stemming from insecure HTTP downloads and a lack of signature validation. AMD initially dismissed the severe bug, citing MITM attacks as 'out of scope', but relented under public pressure, leading to a prolonged disclosure saga. The ultimate irony: the AutoUpdate was already broken by an unrelated redirect bug, rendering the RCE unexploitable, and AMD's eventual 'fix' included laughably weak CRC-32 'signature verification'.
The Lowdown
This story details a white-hat hacker's journey from mild annoyance to uncovering a critical security flaw in AMD's AutoUpdate software and the ensuing, often frustrating, disclosure process. What began with an irritating console pop-up quickly escalated into the discovery of a Remote Code Execution (RCE) vulnerability, highlighting significant shortcomings in AMD's security practices and bug bounty program.
- Vulnerability Discovery: The author, MrBruh, decompiled AMD's AutoUpdate application out of frustration, discovering that while the update URL was HTTPS, the executable download URLs embedded within an XML configuration file were plain HTTP. This allowed for trivial Man-in-the-Middle (MITM) attacks to swap legitimate updates with malicious code, further compounded by the software's complete lack of signature verification for downloaded executables.
- Initial AMD Response: Despite the severity, AMD's bug bounty program initially closed the report as 'out of scope', stating that MITM attacks were not covered by their terms of service.
- Public Disclosure & AMD's Reversal: Following a public blog post, AMD's Product Security Incident Response Team (PSIRT) backtracked, acknowledging the validity of the report and requesting the blog post be taken down, which MrBruh initially agreed to.
- Extended Embargo & Disclosure Issues: AMD then imposed an unusually long embargo period (124 days) for a fix, citing that multiple products were affected and customers needed time. MrBruh noted the fix could be as simple as adding an 's' to HTTP URLs, questioning the delay.
- The Ironic Kicker: It was later discovered that the AutoUpdate functionality was already broken due to its inability to handle a domain redirect, effectively making the RCE unexploitable until the updater itself was fixed. This created a Catch-22 situation.
- Flawed Fix Implementation: AMD eventually implemented a fix, moving the auto-updater functionality to the application layer and using HTTPS. However, their claim of 'signature verification' was found to be a weak CRC-32 check, not cryptographically secure hashing.
- No Compensation: Despite discovering multiple critical vulnerabilities for major tech companies, MrBruh highlighted receiving $0 in bug bounties, with the AMD vulnerability alone being potentially worth ~$10,000 had it been in scope.
This saga serves as a stark reminder of the challenges faced by security researchers and the often-bureaucratic, and sometimes incompetent, responses from large corporations to critical security disclosures, ultimately leaving users vulnerable for extended periods.
The Gossip
Bounty Boundary Blunders
Many commenters expressed disbelief and frustration over AMD's initial stance that MITM attacks were 'out of scope' for their bug bounty program. This sparked a discussion about the arbitrary nature of bug bounty rules and whether companies are truly responsible for security in scenarios like DNS cache poisoning, which might bypass a strict definition of MITM. The sentiment was largely critical of AMD's approach, with some pointing out that 'out of scope' doesn't negate the impact of a vulnerability.
Fix Flaws and Faux Security
The reveal that AMD's 'signature verification' in their patch amounted to a CRC-32 check drew significant derision. Commenters highlighted this as a hilariously inadequate and clueless attempt at security, underscoring a broader lack of understanding or commitment to robust security practices within the company. This particular detail reinforced the overall impression of sloppiness and incompetence.
Researcher's Rigors and Rewarding Recognition
The community largely empathized with the researcher's frustration, both in dealing with annoying software and the subsequent unrewarding disclosure process. Several comments reflected on the 'fruitless' nature of white hat security work nowadays, where finding critical flaws for major companies often leads to no monetary compensation, prolonged delays, and even attempts to silence the researcher, despite the public benefit of their work.