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

# AMD 拒绝修复的 RCE 漏洞！ 来源：https://mrbruh.com/amd2/ 在我新买的游戏电脑上，一个烦人的控制台窗口时不时弹出来，打断我多次后，我成功追踪到了罪魁祸首——AMD 的 AutoUpdate 软件。 一怒之下，我决定惩罚这个软件，把它反编译看看它是怎么工作的，结果意外发现了一个简单的远程代码执行（RCE）漏洞。 我首先发现的是，他们把更新 URL 放在了程序的 `app.config` 里。虽然他们在生产环境中使用“Development”URL 有点奇怪，但它用的是 HTTPS，所以还算安全。 amd_appconfig 真正的麻烦在于，当你在浏览器中打开这个 `.xml` URL 时，你会发现所有可执行文件的下载链接都用的都是 HTTP。 amd_updatexml 这意味着，你网络上的恶意攻击者，或者能访问你 ISP 的某个国家机构，可以轻松进行 MITM 攻击，并用他们选择的任意恶意可执行文件替换掉网络响应。 我原本希望 AMD 可能有某种证书验证，来确保它不会下载并运行未签名的可执行文件。然而，快速浏览一下反编译的代码后发现，AutoUpdate 软件根本没有做这种验证，而是直接执行下载的文件。 amd_installupdates 发现这个问题后，我觉得值得向 AMD 报告，因为它看起来相当严重。 不幸的是，他们漏洞赏金计划的**服务条款声明**“**中间人**”攻击不在范围内，因此报告被以此理由关闭。 amd_disclosure **更新！这个问题在 Hacker News（https://news.ycombinator.com/item?id=46906947）上爆发的当天内，AMD 就联系了我，并表示他们还是会调查此事。** ``` 我是 AMD PSIRT 的。我们仍在内部审查你的报告。请注意，即使 Intigriti 因为不在赏金计划范围内而拒绝了提交，我们仍然乐意审查细节，以确定是否存在任何潜在的有效性。 ``` **注意：** Intigriti 是 AMD 用于初始分类的第三方漏洞赏金平台，而 PSIRT（产品安全事件响应团队）是 AMD 的内部安全团队。 此外，他们要求我在他们修复问题之前撤下这篇博客文章。 ``` 我们得知一篇讨论此问题的博客文章已经发布，这似乎不符合该计划的条款。能否请你撤下文章，等待我们完成审查并提供官方回应？ ``` 我同意了。事后看来，我认为这是错误的决定。 ``` 该报告被标记为“范围外”，因为它不符合当前计划指南的赏金条件：它影响的是可选工具，并且依赖于 MITM 攻击场景。 经过进一步内部审查，我们决定： - 为此漏洞分配一个 CVE - 实施修复 - 给予你安全研究员的致谢 ``` 在我同意在漏洞修复前撤下博客后，他们详细说明不会支付我赏金，因为它是一个可选工具并且需要 MITM，但他们会为这个漏洞分配 CVE 并给予我致谢。 ``` 你打算遵循什么样的披露时间线？ 例如90 + 30天 ``` 我问他们打算对这个漏洞遵循多长的披露期。行业标准是 90 天，并且查看了其他研究人员的文章后，我可以确认 AMD 的大多数漏洞都在 90 天内得到了处理。 ``` 嗨 @mrbruh，我们可能需要更长的保密期，因为除了 Ryzen Master 之外，似乎还有其他工具受到影响，需要发布版本。有更多消息我会及时通知你。 ``` **所以总的来说，以下是本次披露的当前状态：** - 他们声明该漏洞不符合赏金范围，但要求我撤下博客文章，因为它违反了漏洞赏金计划的规则。 - 他们不仅要求我撤下文章，还要求我比行业标准更长时间地保密。 - 他们以该问题可能影响多个软件产品为由，延长了保密期；然而，修复本身可能简单到只需在他们托管的 XML 文件中的 `http` URL 里加一个 `s`（所以修复应该相对容易）。 - 另外，如果这是个严重问题，数百万台电脑随时可能因为 AMD 的多个产品而被黑，那么快速修复应该是优先事项，不是吗？ 我最终又多等了 69 天，从披露到再次联系他们总共等了 87 天。 我告诉他们，我不能无限期地等着他们修复这个问题，我计划在最初披露后的第 100 天再次发布我的文章。 尽管 AMD 承诺会及时通知我，但他们没有主动保持更新。他们只在保密期结束前几天告诉我这个漏洞的修复方法（而且是在我明确询问之后）。 ``` 多个可选工具受到影响。我们正在等待至少其中一个工具的发布。此外，我们的客户要求在修复可用后给予额外时间来审查。所以我们请求你推迟公开披露，以便给客户更多时间。 ``` 他们一开始只是要求“更多时间”，没有明确披露期，但两天后他们同意在 6 月 9 日结束保密期。 ``` 嗨 @mrbruh，我已要求工程团队加快速度，以便我们能在 6 月 9 日进行披露。会保持更新。 ``` 我计划发布这篇更新的文章，距离最初披露总共**124 天**。 **124 天才让 AMD 在一堆 HTTP URL 里加了个 `s`！** ## 关键点 我认为 AMD 准备的任何修复方案都不重要了。 根据我原帖在 Hacker News 帖子中发布的[一个链接](https://reddit.com/r/AMDHelp/comments/ysqvsv/amd_autoupdateexe/mltu3z2/)，该自动更新程序因为第二个完全不相关的原因已经完全失效了。 他们曾在某个时候把软件包列表的主机从 ati.com 改为了 drivers.amd.com。 在浏览器中打开 XML URL 会自动重定向到新域名。然而，AutoUpdater 程序无法处理这个重定向，导致它崩溃或卡住。 amd_reddit_post 奇怪的是，这意味着我发现的漏洞实际上无法利用，因为 AutoUpdater 在完全崩溃之前根本不会执行到那段代码。 这也导致了一种两难局面：你需要更新更新程序来修复漏洞，但更新程序在重定向 bug 修复之前不会更新。真好。 干得好 AMD GIF 如果你是安装了 AMD 软件的 AMD 用户，我强烈建议完全卸载所有内容，然后从他们网站下载新版本。 **最终更新：** 在保密期结束前几天（以及我写完这篇博客的大部分内容之后），AMD 告诉我他们对这个漏洞的修复方案是： ``` 嗨 @mrbruh，在 Ryzen Master 中，自动更新功能已从安装程序中移除，并移到了应用层。 在应用内部，所有更新通信都使用 HTTPS 进行保护，并且更新会经过签名验证。 ``` 我随后验证了这些声明。虽然他们现在确实完全使用了 HTTPS，但关于签名验证的声明是不真实的；他们只对下载的可执行文件执行 CRC-32 检查，这在密码学上是不安全的。 ## 捐赠 到目前为止，我向 Google、ASUS、AMD、TP-Link、MSI（以及其他公司）报告的漏洞，总共赔付了 0 美元。如果 AMD 的漏洞在范围内，本应赔付约 1 万美元。 如果你觉得这篇文章有趣或有帮助，你可以通过我的 KoFi 请我喝杯咖啡：https://ko-fi.com/mrbruhh ## 时间线（日/月/年） - 2026年1月27日 - 发现漏洞（由我） - 2026年2月6日 - 报告漏洞 - 2026年2月6日 - 漏洞被标记为“不会修复/范围外” - 2026年2月6日 - 博客发布 - 2026年2月7日 - AMD 反悔，表示会调查此事 - 2026年6月9日 - 保密期结束，**历时124天**