The RCE that AMD wouldn’t fix
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.
... continue reading