AMD AutoUpdate 远程代码执行漏洞披露

AMD AutoUpdate 漏洞概述

在 AMD 的 AutoUpdate 软件中发现了一个严重的远程代码执行 (RCE) 漏洞，允许恶意攻击者在目标系统上执行任意代码。该漏洞源于软件通过未加密的 HTTP 下载可执行更新，使得中间人 (MITM) 攻击能够将合法的更新替换为恶意负载。

技术根本原因：未加密的更新交付

该漏洞是通过对 AutoUpdate 可执行文件的反编译发现的。虽然存储在 app.config 文件中的初始更新 URL 使用了 HTTPS，但该 URL 托管的 XML 文件中包含了使用纯 HTTP 下载可执行文件的链接。

由于 AutoUpdate 软件不对下载的文件进行证书验证或签名验证，它会立即执行从这些 HTTP URL 接收到的任何文件。这使得任何具有网络访问权限的攻击者（例如本地网络上的恶意攻击者或具有拦截能力的 ISP）能够拦截 HTTP 请求并提供恶意可执行文件来代替官方的 AMD 更新。

披露时间线与厂商响应

从最初发现到公开披露，整个披露过程历时 124 天。时间线突显了研究人员报告与厂商修复之间的显著差距：

  • 2026 年 1 月 27 日： 漏洞被发现。
  • 2026 年 2 月 6 日： 漏洞向 AMD 报告。
  • 2026 年 2 月 6 日： AMD 的第三方分诊合作伙伴 Intigriti 将该报告关闭，标记为“超出范围”，因为 MITM 攻击被排除在漏洞赏金计划指南之外。
  • 2026 年 2 月 7 日： 在 Hacker News 上引起公众关注后，AMD 的内部产品安全事件响应团队 (PSIRT) 重新开启了该案例进行内部审查。
  • 2026 年 6 月 9 日： 禁运期结束，漏洞被公开披露。

在整个过程中，AMD 请求了超出行业标准 90 天的延长禁运期，理由是多个可选工具受到影响并需要协调发布。

“意外的安全”漏洞

有趣的是，由于一个单独的、无关的软件漏洞，该漏洞在许多情况下实际上是无法利用的。AMD 已将其软件安装包托管从 ati.com 迁移到了 drivers.amd.com。虽然 Web 浏览器可以自动处理由此产生的重定向，但 AutoUpdate 程序无法处理重定向，导致软件在到达负责下载基于 HTTP 的可执行文件的代码之前就崩溃或锁死。

修复方案与遗留的安全差距

AMD 的最终修复方案包括从安装程序中移除自动更新功能，并将其移至应用层（专门针对 Ryzen Master）。更新后的实现方式对所有通信都使用 HTTPS。

然而，研究人员对补丁的验证显示了一个显著的遗留安全差距：虽然 AMD 声称实现了“签名验证”，但软件实际上仅对下载的可执行文件进行 CRC-32 校验。

“虽然他们现在确实完全使用了 HTTPS，但关于签名验证的说法是不真实的；他们仅对下载的可执行文件进行 CRC-32 校验，这在密码学上是不安全的。”

由于 CRC-32 是一种错误检测码而非密码学签名，如果服务器本身被攻破，它无法防止蓄意的篡改。社区成员指出，这种实现方式“极其荒谬且无知”，无法针对复杂的攻击者提供真正的密码学安全保护。

Sources