The RCE that AMD wouldn’t fix! | MrBruh's Epic Blog
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.
I am writing from AMD PSIRT. We are still conducting an internal review of your report. Please note that even if Intigriti has rejected the submission as out of scope for the bounty program, we are still happy to review the details to determine whether there may be any potential validity.<br>Note: Intigriti is the third-party bug bounty platform AMD uses for initial triage, while PSIRT (Product Security Incident Response Team) is AMD’s internal security team.
Additionally, they requested I take down the blog post until they patched the issue.
We were informed that a blog post discussing this issue has already been published, which does not appear to be in accordance with the program’s terms. Could you please take the post down and wait for us to complete our review and provide an official response?<br>I agreed to do so, which, in hindsight, I believe was the wrong choice to make.
The report was marked out of scope because it is not eligible for a bounty under our current program guidelines, as it affects optional tools and relies on a MITM attack scenario.
After further internal review, we've decided to:
- Issue a CVE for this vulnerability<br>- Implement a fix<br>- Provide you with security researcher recognition<br>After agreeing to take down my blog until the vulnerability was patched, they followed up by detailing that they would not be paying me because it’s an optional tool and requires MITM, but instead they would be issuing a CVE for this and giving me credit.
What disclosure timeline you intend to follow?
e.g 90 + 30 days<br>I asked them what disclosure period they were planning to follow for this issue. The industry standard is 90 days, and after looking at other researchers’ write-ups, I can confirm the majority of AMD’s vulnerabilities were addressed within 90 days.
Hi @mrbruh, We will likely need a longer embargo, as additional tools beyond Ryzen Master appear to be impacted and will need releases. I’ll keep you updated as we learn more.<br>So in summary, this is the current state of the disclosure:
They declared it out of scope for a bounty, but requested that I take down the blog post because it was breaking the bug bounty’s rules.
Not only did they ask me to take the blog post down, but they also asked me to keep it down for an extended duration compared to the industry standard.
They justified this extended embargo period by saying that this issue might affect several of their software products; however, the patch itself could be as simple as adding a single s to an http URL in their hosted XML file (so it should be relatively easy to fix).
Also, if this is such a big issue that millions of people’s computers could get hacked at any time from a number of AMD’s products, then it should be a priority to fix this quickly, no?
I ended up waiting an additional 69 days, for a total of 87 days from disclosure until I reached out again.
I told them that I could not continue to wait an indefinite amount of time for them to fix this issue, and that I planned to publish my write-up again at 100 days after initial disclosure had passed.
AMD did not actively keep me updated, despite assuring me they would. They only told me...