The RCE that AMD wouldn’t fix

AMD 不愿修复的远程代码执行漏洞 (RCE)

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.

在我的新游戏电脑上，一个恼人的控制台窗口周期性地弹出，多次打断我的工作。在追踪后，我发现罪魁祸首是 AMD 的 AutoUpdate 软件。出于沮丧，我决定“惩罚”这个软件，通过反编译来研究它的工作原理，并在此过程中意外发现了一个简单的远程代码执行 (RCE) 漏洞。

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.

我首先发现他们将更新 URL 存储在程序的 app.config 中。虽然在生产环境中使用“开发”URL 有点奇怪，但它使用的是 HTTPS，所以是完全安全的。真正的问题在于，当你在浏览器中打开这个 .xml URL 时，会发现所有可执行文件的下载链接都使用的是 HTTP。这意味着你网络中的恶意攻击者，或者能够访问你 ISP 的国家级行为体，可以轻松执行中间人 (MITM) 攻击，并将网络响应替换为他们选择的任何恶意可执行文件。

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.

我曾希望 AMD 至少有某种形式的证书验证，以确保它不会下载并运行任何未签名的可执行文件。然而，快速查看反编译代码后发现，AutoUpdate 软件根本没有进行此类验证，而是直接执行了下载的文件。发现这一点后，我认为有必要向 AMD 报告，因为它看起来相当严重。遗憾的是，他们的漏洞赏金计划服务条款规定中间人攻击不在范围之内，因此该报告被直接关闭。

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. 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.

更新！在 Hacker News 上引发热议不到一天，AMD 就联系了我，表示他们最终还是会调查此事。“我是代表 AMD PSIRT 写信给您的。我们仍在对您的报告进行内部审查。请注意，即使 Intigriti 已将该提交视为赏金计划范围外，我们仍乐意审查详细信息，以确定其是否存在潜在的有效性。”注：Intigriti 是 AMD 用于初步分类的第三方漏洞赏金平台，而 PSIRT（产品安全事件响应团队）是 AMD 的内部安全团队。

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? 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 - Implement a fix - Provide you with security researcher recognition. 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.

“该报告被标记为范围外，因为它不符合我们当前计划指南下的赏金资格，因为它影响的是可选工具且依赖于 MITM 攻击场景。经过进一步内部审查，我们决定：- 为此漏洞发布 CVE - 实施修复 - 为您提供安全研究员认可。”在同意撤下博客直到漏洞修复后，他们后续详细说明，由于这是可选工具且需要 MITM，他们不会支付赏金，但会为此发布 CVE 并给予我署名。

What disclosure timeline you intend to follow? e.g 90 + 30 days. 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.

“您打算遵循什么披露时间表？例如 90 + 30 天。”我询问他们计划为此问题遵循什么披露周期。行业标准是 90 天，在查看了其他研究人员的文章后，我可以确认 AMD 的大多数漏洞都在 90 天内得到了解决。

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. 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.

“你好 @mrbruh，我们可能需要更长的禁令期，因为除了 Ryzen Master 之外，其他工具似乎也受到了影响，需要发布更新。随着我们了解更多信息，我会随时通知你。”总之，这就是披露的现状：他们宣布该漏洞不在赏金范围内，但要求我撤下博客文章，因为它违反了漏洞赏金计划的规则。他们不仅要求我撤下文章，还要求我将其撤下的时间比行业标准延长了许多。

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?

他们为延长的禁令期辩解称，此问题可能影响其多款软件产品；然而，修复本身可能只需在托管的 XML 文件中将 http URL 改为 https（只需添加一个 ‘s’），这应该很容易修复。此外，如果这是一个如此严重的问题，导致数百万人的电脑随时可能被 AMD 的多款产品入侵，那么优先快速修复它不是理所应当的吗？

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 what the fix for this vulnerability was a couple of days before the embargo ended (and only after I explicitly asked).

我最终又等了 69 天，从披露开始算起总共 87 天，直到我再次联系他们。我告诉他们，我不能无限期地等待他们修复这个问题，并计划在最初披露 100 天后重新发布我的文章。尽管 AMD 向我保证会随时通知我，但他们并没有主动这样做。直到禁令结束前几天（且在我明确询问后），他们才告诉我该漏洞的修复方案。

Multiple optional tools are affected by this. We are awaiting release on at least one of them. Moreover, our customers request additional time to review fixes once they are made available. So we request you to hold public disclosure to give additional time for customers. They initially just asked for “more time”, without specifying a disclosure period, but two days later they agreed to end the embargo on June the 9th.

“多个可选工具受到此问题影响。我们正在等待其中至少一个工具的发布。此外，我们的客户要求在修复程序发布后有额外的时间进行审查。因此，我们请求您推迟公开披露，以便给客户更多时间。”他们最初只是要求“更多时间”，没有指定披露期限，但两天后他们同意在 6 月 9 日结束禁令。

Hi @mrbruh, I have asked the engineering teams to expedite this so we can disclose it on June 9th. Will keep you updated. I am planning to publish this updated write-up, a total of 124 days after initial disclosure. 124 days to get AMD to add an s to a couple of HTTP URLs! The Kicker I don’t think it even matters what patch AMD has cooked up to fix this issue. According to a link posted in the Hacker News thread of my original post, the auto updater is completely broken due to a second, entirely unrelated reason. They switched from hosting their list of software packages on ati.com to drivers.amd.com at some point.

“你好 @mrbruh，我已经要求工程团队加快进度，以便我们能在 6 月 9 日披露。我会随时通知你。”我计划在最初披露 124 天后发布这篇更新后的文章。为了让 AMD 在几个 HTTP URL 中加一个 ‘s’，竟然花了 124 天！最讽刺的是，我认为 AMD 搞出的修复补丁根本不重要。根据我原始文章在 Hacker News 帖子中的一个链接，自动更新程序由于第二个完全无关的原因已经彻底损坏了。他们在某个时间点将软件列表的托管地址从 ati.com 切换到了 drivers.amd.com。