AMD has denied a security researcher a $10,000 bug bounty despite the individual's work and cooperation with the company. Regulars at this pub might remember an article a while back about a security researcher who diagnosed a potential remote code execution (RCE) via a man-in-the-middle attack (MITM) in AMD's auto-updater software. Paul, the researcher, submitted a report at AMD's bug bounty program website, expecting both a fix and a payout for an RCE-class bug. The report was turned down as MITM attacks weren't covered by the program's policy. Nevertheless, Paul took down the blog post describing the situation due to AMD's request. It's now come back online, and the whole situation merits a facepalm or three.
First, the good news: the updater is now seemingly secured, and you if you download the latest version of AMD's software pack, you ought to get a fixed version. The road to this point has been far from smooth, though, and to this day, Paul seemingly never saw a dime for his efforts, a story that is becoming commonplace if Microsoft's issues with Nightmare-Eclipse are anything to go by. An RCE bug would otherwise be worth $10,000 if AMD fully acquiesced the significance of problem.
The updated post contains the full story, and it goes as follows: Back in February, when AMD asked Paul to bring down the blog post temporarily, the company said it would issue a standard CVE, fix the software, and attribute the findings to him, though a bounty payment was out of the question. Paul agreed (a decision he now regrets), though he asked what kind of timeline AMD would follow, suggesting the industry-standard 90-day window until he posted the public disclosure again.
AMD replied saying that it would "likely need a longer embargo, as additional tools beyond Ryzen Master appear[ed] to be impacted and [would] need releases." That was an interesting statement in several ways: first, it raises the question exactly why AMD would need so long to publish what was seemingly a one-character fix, replacing "http" with "https" in the code. Second, if the issue was bad enough to require so long to solve, then arguably Paul's work would merit some recompense. Third, as Paul pointed out, if this issue looked this pressing, why didn't it have a higher priority?
Nevertheless, he ended up agreeing on a 100-day window, and asked AMD the equivalent of "wassup?" before the clock ticked its last tock, only to be asked for extra time again, being told that "multiple tools are affected by [the bug]", and that "[AMD's] customers request additional time once [the fixes] are made available." Eventually, AMD reached out stating that a fix would be ready on June 9, totaling 124 days after the initial finding.
To its credit, AMD seemingly reengineered the download code in the autoupdater altogether, and Paul verified that the new version does indeed download drivers securely, though he remarks that the software only checks the validity of the downloaded file using the ancient CRC32 hash that isn't considered cryptographically secure anymore.
Here's where irony strikes, though: according to a Reddit user, the bug that Paul found seemingly wouldn't be triggered anyway, as the relevant section of the code wasn't being called to begin with, meaning the updater was broken. So AMD couldn't update the updater because the updating code couldn't update, necessitating a fresh download on behalf of users. Quis renovatores renovat indeed.
Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.