AMD 拒绝修复的 RCE 漏洞：一次典型的漏洞披露博弈

背景

近期，一位安全研究员（在 Hacker News 上被称为 @mrbruh）在排查其新游戏 PC 上周期性弹出的烦人控制台窗口时，追踪到了罪魁祸首：AMD 的 AutoUpdate 软件。出于挫败感，该研究员决定反编译该软件以探究其工作原理，却意外发现了一个极其简单的远程代码执行（RCE）漏洞。

这一发现引发了关于漏洞披露流程、厂商响应机制以及“范围外（Out of Scope）”定义的激烈讨论。尽管 AMD 最终承认了漏洞并分配了 CVE，但其处理过程充满了拖延、矛盾以及对安全研究员的苛刻要求，最终导致披露周期远超行业标准的 90 天。

核心内容

1. 漏洞发现与原理 研究员在反编译 AMD AutoUpdate 软件时发现，该软件将更新 URL 存储在 app.config 文件中。虽然生产环境中使用了“Development” URL 略显奇怪，但使用的是 HTTPS，看似安全。然而，当研究员在浏览器中打开该 .xml 配置文件时，发现所有可执行文件的下载链接均使用 HTTP 协议。

这意味着，处于同一网络环境的攻击者，或能访问用户 ISP 的国家行为体，可以轻易执行中间人攻击（MITM），将网络响应替换为攻击者选择的任何恶意可执行文件。更严重的是，反编译代码显示，AutoUpdate 软件在接收下载文件后不进行任何证书验证或签名检查，直接执行下载的文件。

2. 报告受阻与“范围外”争议 研究员向 AMD 报告了该严重漏洞。然而，AMD 的漏洞赏金计划（通过第三方平台 Intigriti 进行初步筛选）的条款规定，中间人攻击（MITM）场景属于“范围外（Out of Scope）”，因此该报告最初被标记为“不予修复/范围外”。

值得注意的是，Intigriti 是 AMD 用于初步分诊的第三方平台，而 PSIRT（产品安全事件响应团队）是 AMD 的内部安全团队。PSIRT 随后联系研究员，表示尽管 Intigriti 拒绝了赏金资格，但他们仍愿意审查细节以确定漏洞的有效性，并要求研究员在修复前撤下已发布的博客文章。

3. 漫长的披露拉锯战 研究员同意撤下文章，但随后陷入了漫长的等待。AMD 以“影响多个可选工具”和“需要给客户更多时间审查”为由，要求延长保密期（Embargo），这远超行业标准的 90 天。

• 沟通缺失：AMD 未主动更新进展，仅在研究员追问后才透露修复方案的大致方向。
• 最终期限：经过 69 天的额外等待，研究员在披露后第 100 天再次联系 AMD，表示无法无限期等待。最终，AMD 同意在披露后第 124 天（6 月 9 日）解除保密限制。
• 赏金争议：AMD 明确表示，由于该漏洞涉及“可选工具”且依赖“MITM 场景”，不符合赏金计划，因此不会支付约 1 万美元的赏金，仅会分配 CVE 编号并给予研究人员署名认可。

4. 讽刺的结局：漏洞实际上不可利用？ 文章发布前出现了极具讽刺意味的反转。根据 Hacker News 线程中的信息，AMD 的自动更新程序因另一个完全无关的原因已完全失效：AMD 将软件包列表的主机从 ati.com 迁移到了 drivers.amd.com。虽然浏览器访问 XML URL 会自动重定向到新域名，但 AutoUpdate 程序无法处理此重定向，导致程序崩溃或卡死。

这意味着，研究员发现的 RCE 漏洞实际上不可利用，因为自动更新程序在到达下载恶意代码的逻辑之前就已经崩溃了。这形成了一个“Catch-22”困境：你需要更新更新程序来修复 RCE 漏洞，但更新程序本身因重定向 bug 而无法更新。

5. 补丁的真实有效性 在保密期结束前几天，AMD 透露了修复方案：在 Ryzen Master 中，自动更新功能已从安装程序移除并移至应用层，所有通信均使用 HTTPS，并进行签名验证。 然而，研究员验证后发现，虽然 HTTPS 已全面启用，但所谓的“签名验证”仅包含对下载可执行文件的 CRC-32 校验。CRC-32 并非密码学安全的校验算法，无法防止恶意篡改，因此该修复并不彻底。

关键要点

• 漏洞本质：AMD AutoUpdate 软件通过 HTTP 下载可执行文件且无完整性校验，存在严重的 RCE 风险，理论上允许 MITM 攻击者植入恶意软件。
• 赏金计划的局限性：AMD 的漏洞赏金计划将 MITM 场景和“可选工具”排除在外，导致研究员虽发现严重漏洞却无法获得经济奖励，仅获 CVE 编号。
• 披露周期的滥用：AMD 以“客户审查时间”为由，将保密期延长至 124 天，远超行业标准的 90 天，且期间缺乏透明沟通。
• 修复方案的缺陷：AMD 声称实施了签名验证，但实际仅使用了不安全的 CRC-32 校验，未能提供真正的密码学安全保障。
• 讽刺的现实：由于自动更新程序因域名重定向问题已崩溃，该 RCE 漏洞在现实中可能无法被利用，但这并未改变 AMD 安全架构中存在的严重设计缺陷。
• 零报酬记录：该研究员向 Google、ASUS、AMD、TP-Link、MSI 等公司报告漏洞，累计获得的赏金总额为 $0。

意义与影响

1. 漏洞赏金计划的“范围外”陷阱 此次事件揭示了大型科技公司漏洞赏金计划中的一个常见痛点：厂商往往通过宽泛的“范围外”条款（如排除 MITM、排除非核心组件）来规避高额赏金支付。虽然从合规角度看，厂商有权设定规则，但这会打击安全研究员的积极性，并可能导致关键安全漏洞被低估或忽视。AMD 在舆论压力下最终分配 CVE 并承认漏洞，显示了公众舆论对厂商决策的制约作用。

2. 软件供应链安全的脆弱性 AMD AutoUpdate 的案例反映了软件供应链更新机制中的典型弱点：

• 协议降级：在配置文件中硬编码 HTTP 链接，而非强制 HTTPS。
• 完整性校验缺失：依赖易被篡改的 CRC-32 而非数字签名（如 RSA/ECDSA）。
• 错误处理不当：程序无法处理正常的 HTTP 重定向，导致服务中断。 这些低级错误表明，即使是大型硬件厂商，其软件安全工程实践也存在显著短板。

3. 披露伦理与厂商响应 AMD 要求研究员在漏洞未修复前撤下文章，并试图延长保密期，这在安全社区引发了关于“负责任披露”边界的讨论。虽然厂商需要时间修复，但过长的保密期会使公众长期处于风险之中。AMD 最终在 124 天后才解除保密，且修复方案并不完善，这损害了其安全信誉。

4. 对用户的建议 对于 AMD 用户而言，该事件是一个警示：

• 不要盲目信任自动更新机制的完整性。
• 鉴于自动更新程序存在重定向崩溃问题，建议用户完全卸载现有 AMD 软件，并从官网手动下载最新版本。
• 关注关键系统组件（如驱动更新程序）的安全配置，定期检查其网络通信是否加密及文件完整性校验方式。

5. 安全研究员的困境 该研究员的经历（零赏金、被要求撤稿、漫长的等待）代表了众多独立安全研究员面临的现实挑战。尽管他们为提升网络安全做出了贡献，但缺乏制度性的保障和公平的补偿机制，可能导致人才流失或披露意愿下降。安全社区需要推动更透明、更公平的漏洞披露和赏金支付标准。