一名安全研究员在追踪一个恼人的弹窗时，意外发现了 AMD AutoUpdate 软件中的一个远程代码执行（RCE）漏洞。这个看似简单的发现，却演变成了一场长达 124 天的漏洞披露拉锯战，暴露出供应链安全中更新机制设计的系统性风险。
漏洞发现：从弹窗到代码审计
故事始于研究员的新游戏电脑 ——AMD AutoUpdate 组件会周期性地弹出命令行窗口打断用户工作。出于 "惩罚" 这个软件的目的，研究员对其进行了反编译分析，却意外发现了一个可被轻易利用的 RCE 漏洞。
技术层面的问题出在两个关键环节：
** 第一，HTTP 明文传输。** 虽然 AutoUpdate 的配置文件（app.config）中存储的更新元数据 URL 使用了 HTTPS，但该 URL 返回的 XML 清单中，所有可执行文件的下载链接均使用 HTTP 明文协议。这意味着任何能够进行中间人攻击（MITM）的实体 —— 无论是本地网络中的恶意用户，还是具备 ISP 级别访问能力的国家级行为体 —— 都可以拦截并篡改下载内容。
** 第二，缺乏代码签名验证。** 研究员原本期望 AMD 至少会验证下载文件的数字签名，但反编译结果显示，AutoUpdate 组件在下载完成后立即执行文件，没有任何签名验证或完整性检查机制。这种设计使得攻击者只需替换 HTTP 响应中的下载链接，即可让目标系统执行任意恶意代码。
披露困境：从 "超出范围" 到公共压力
研究员于 2026 年 2 月 6 日向 AMD 报告了该漏洞，但当天即被标记为 "won't fix/out of scope"（不予修复 / 超出范围）。AMD 的理由是其漏洞赏金计划的条款明确将中间人攻击列为排除项。
然而，在原始博客文章于 Hacker News 引发广泛关注后，AMD 的态度发生了 180 度转变。PSIRT（产品安全事件响应团队）主动联系研究员，表示将重新评估该报告，并要求撤下博客文章以待修复完成。这种 "先拒绝、后重视" 的响应模式，折射出漏洞披露中厂商与研究者之间的权力不对等。
更具争议的是 AMD 对披露时间线的处理。尽管行业标准的 90 天披露期限是广泛接受的惯例，AMD 却以 "多个可选工具受影响" 为由要求延长禁运期。最终，从初次报告到公开披露历时 124 天 —— 而这仅仅是将 HTTP 改为 HTTPS 并添加基本验证的改动。
修复方案的局限性
AMD 最终的修复方案包括两个层面：将自动更新功能从安装程序移至应用层，以及使用 HTTPS 加密通信。然而，研究员验证后发现，AMD 声称的 "签名验证" 实际上只是 CRC-32 校验 —— 这是一种用于检测意外数据损坏的循环冗余校验算法，而非具备密码学安全性的数字签名验证机制。
CRC-32 的设计目标是检测传输错误，而非抵御恶意篡改。攻击者可以轻易构造具有相同 CRC-32 值但内容完全不同的恶意文件，使得这种 "验证" 在安全层面形同虚设。这一选择反映出对密码学原语适用场景的误解，也可能暗示着在安全性与向后兼容性之间的妥协。
意外的讽刺：Updater 早已损坏
整个事件中最具讽刺意味的转折是：在漏洞被发现之前，AutoUpdate 组件实际上已经无法正常工作。由于 AMD 将软件包托管从 ati.com 迁移至 drivers.amd.com，而 AutoUpdate 程序无法处理这一域名重定向，导致更新流程在到达漏洞代码路径之前就已经崩溃。
这就形成了一个 "第二十二条军规" 式的困境：用户需要更新 AutoUpdate 来修复安全漏洞，但 AutoUpdate 本身因为重定向问题无法更新。这种技术债务的累积，使得安全修复的部署路径变得异常复杂。
供应链安全的启示
这一案例为软件供应链安全提供了多个可操作的教训：
** 更新通道的安全基线。** 所有软件更新机制应强制使用 HTTPS，并实施严格的传输层证书验证。HTTP 明文传输在现代软件分发中已无任何立足之地。
** 代码签名的必要性。** 下载后的可执行文件必须经过加密强度足够的数字签名验证，而非简单的完整性校验。SHA-256 配合 RSA/ECDSA 签名是当前的最低标准。
** 漏洞披露的透明度。** 厂商应建立清晰的漏洞评估标准，避免在公众关注前后采取双重标准。同时，对披露时间线的协商应基于具体技术复杂度，而非笼统的 "需要更多时间"。
** 技术债务的连锁效应。** 域名迁移、API 变更等基础设施层面的决策，可能意外阻断安全更新通道。在架构演进过程中，需要评估对现有安全机制的兼容性影响。
结语
AMD AutoUpdate RCE 漏洞的披露过程，揭示了即使是大型硬件厂商也可能在软件供应链安全的基本实践上存在盲点。从 HTTP 明文下载到 CRC-32 伪验证，这些设计选择反映出安全优先级的系统性缺失。对于企业安全团队而言，这一案例强调了审计第三方软件更新机制的必要性 —— 在供应商修复之前，禁用或限制此类组件的网络访问可能是务实的风险缓解措施。
参考来源
- MrBruh 安全研究员博客：The RCE that AMD wouldn't fix!
- Hacker News 讨论线程及相关社区反馈
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。