AMD 拒付 1 万美元漏洞赏金：安全更新背后的信任危机

背景

在网络安全领域，发现关键漏洞的研究者通常期望通过漏洞赏金计划（Bug Bounty Program）获得奖励，这既是对专业能力的认可，也是激励社区协助厂商修补安全缺陷的重要机制。然而，AMD 近期的一起事件打破了这一惯例。

AMD 的自动更新程序被发现存在严重的安全漏洞，允许网络攻击者在常规更新过程中通过不安全的 HTTP 连接注入恶意代码。发现该远程代码执行（RCE）漏洞的研究者 Paul LaRosa 预期能获得 10,000 美元的赏金，但 AMD 在修复问题后并未支付任何款项，反而以政策为由拒绝了赏金请求。这一事件不仅暴露了 AMD 在安全响应机制上的迟缓，也引发了关于大型科技公司如何处理漏洞披露和赏金政策的广泛争议。

核心内容

1. 漏洞机制：被劫持的信任通道

Paul LaRosa 发现，AMD 用于 Windows 系统的自动更新程序（包括 Ryzen Master 及其他实用工具）通过未加密的 HTTP 连接下载更新。这意味着，任何处于同一网络环境下的攻击者都可以实施中间人攻击（Man-in-the-Middle Attack），将合法的驱动程序替换为恶意软件。

这就好比点外卖时，陌生人可以在餐厅到你家的途中拦截并替换你的餐食。用户的系统会毫无保留地安装攻击者提供的任何内容，因为表面上它看起来来自 AMD。这种漏洞使得攻击者能够轻易实现远程代码执行，从而完全控制受影响的用户设备。

2. 响应迟缓：从 90 天拖延至 124 天

AMD 承认漏洞属实，但拒绝支付赏金，理由是“中间人攻击”属于其漏洞赏金政策的排除范围。在披露时间线上，AMD 的表现远低于行业最佳实践：

• 初始阶段： LaRosa 提出了 90 天的披露窗口。
• 二月： AMD 要求延迟公开披露，并承诺在 90 天内修复。
• 后续： AMD 多次要求延长修复时间。
• 最终结果： 最终补丁在首次报告后的第 124 天才发布。

相比之下，行业最佳实践建议关键漏洞应在 5 到 14 天内修补。将修复关键安全更新机制的漏洞耗时延长至四个月，被形容为“医生发现癌症却安排下个季度治疗”般的荒谬。

3. 修复不彻底：脆弱的 CRC32 校验

尽管 AMD 最终发布了补丁，重新设计了自动更新程序以使用加密下载，但修复方案本身存在严重缺陷。更新后的软件仍然使用 CRC32 对下载的文件进行校验。

CRC32 是一种校验和算法，其安全性极低，类似于“纱门”般的防护，容易被确定的攻击者操纵。现代软件安全标准要求使用经过密码学签名的更新包，以确保文件来源的真实性和完整性，防止任何形式的篡改。AMD 的修复仅解决了表面问题，却留下了更深层的安全弱点。

关键要点

• 漏洞性质严重： AMD Windows 自动更新程序通过不安全的 HTTP 连接下载，导致中间人攻击者可注入恶意代码，实现远程代码执行。
• 赏金被拒理由： AMD 以“中间人攻击”属于政策排除项为由，拒绝了 Paul LaRosa 提出的 10,000 美元赏金请求。
• 响应速度滞后： 从报告到最终修复耗时 124 天，远超关键漏洞 5-14 天的行业标准修复窗口。
• 修复方案存在缺陷： 补丁虽引入了加密，但仍依赖安全性极低的 CRC32 校验和，而非更安全的密码学签名机制。
• 厂商策略质疑： 事件反映出部分大型厂商倾向于利用政策漏洞规避赏金支付，并在修复时优先解决表面问题而非根本性安全架构缺陷。

意义与影响

1. 对研究者的威慑效应

AMD 拒绝支付赏金的行为可能会打击安全研究者的积极性。如果发现关键漏洞不仅得不到奖励，还要面对漫长的等待和不合理的政策解释，研究者可能会选择直接公开漏洞以施加舆论压力，或者转向其他更尊重研究者的平台。这将削弱厂商通过赏金计划主动发现漏洞的能力。

2. 用户信任的侵蚀

自动更新机制是用户信任的基础，用户期望厂商能安全、及时地推送补丁。AMD 的迟缓响应和不彻底的修复方案表明，其安全优先级可能低于成本控制。用户不得不质疑：还有哪些其他“安全”的自动更新程序存在类似的脆弱性？厂商是更关心系统安全，还是更关心漏洞赏金的预算？

3. 行业安全标准的反思

此事件凸显了当前漏洞赏金政策中存在的模糊地带和滥用风险。许多厂商利用复杂的条款排除特定类型的攻击（如中间人攻击），从而规避责任。同时，它也提醒行业，真正的安全修复不应仅满足于引入加密，更应关注数据完整性的密码学保证。对于关键基础设施和驱动程序更新，5-14 天的快速响应应成为硬性标准，而非可协商的建议。