AMD 拒绝修复的 RCE

漏洞与影响

• AMD 的 Windows 工具（例如 Ryzen Master）自带一个自动更新器，使用明文 HTTP 获取更新元数据和二进制文件。
• 这使得通过 MITM 或相关攻击（例如 DNS 污染）可以实现远程代码执行，不过也有人指出该更新器实际上处于半失效状态，这限制了“批量”利用的可能性。
• 一些评论者强调，任何能够运行代码的厂商自动更新器都必须把整个互联网视为不可信，并防范 MITM。

漏洞赏金范围与激励

• AMD 的赏金供应商起初以 MITM 被排除在外为由，将该报告驳回为“超出范围”。
• 一方认为这是标准做法：赏金只是用来引导内部工程优先级的狭窄工具，而不是全面的安全项目，而且公司通常有支付的动机。
• 另一些人认为，“超出范围”实际上等同于“我们不想为此付费或修复”，而外部观察者只能看到严重漏洞被忽视了数月。
• 也有人质疑假设内部激励总是与支付赏金一致是过于乐观的，指出企业普遍存在激励错配。

AMD 的修复与 CRC32“签名”

• AMD 最终把更新器改为使用 HTTPS，但据称只用 CRC32 来“验证”下载内容。
• 多位评论者称这很缺乏安全常识：CRC32 用于检测意外损坏，而不是恶意篡改，而且极易碰撞。
• 也有人指出真正缺失的是代码签名验证；理论上，HTTPS 加上正确的签名就足够了。

威胁模型与 MitM

• 关于将 MITM 排除在赏金范围之外的争论：一些人认为这是在限制环境责任；另一些人则说，HTTP 上的 MITM 且没有任何密码学检查，显然应在范围内。
• 还有人将其与将社工攻击排除在赏金外相比较；批评者说这不同，因为这里不需要任何人为交互。

对 AMD 软件的更广泛批评

• 许多评论把 AMD 的软件和驱动描述为长期糟糕：漏洞百出的工具、糟糕的风扇曲线、烦人的弹窗、GPU 计算方面长期存在的问题。
• 批评还延伸到 ROCm、HIP，以及被放弃或薄弱的 OpenCL 支持，被视为相较于 CUDA 的自我削弱。
• 有人推测公司文化低估了软件的重要性，并且对工程师支付不足。

伦理、披露与反应

• 不少人认为，这件事表明白帽工作和漏洞赏金正变得越来越不受待见。
• 有人主张当厂商拖延或借范围规则搪塞时，应更早全面公开披露。
• 还有人提议为研究者众筹一个“赏金”。
• 文中还出现了一些关于可能存在国家级后门的轻度猜测，但也有人将其归因为单纯的疏忽。