🔌 124 天给 AMD 加一个 's'——一个 RCE 漏洞的披露马拉松
目录
- 一个弹窗引发的血案
- HTTP 上的 .exe — 这甚至不算漏洞
- Bug Bounty 的奇妙逻辑：MITM 不算安全风险
- 社区的反应：不是"会不会被黑"，而是"这都修不了"
- 更讽刺的 twist：这个更新器自己在用的路上就挂了
- 124 天之后
拆开一台新电脑，装好驱动，重启。突然一个控制台窗口弹出来，闪了一下然后消失。
大多数人会忽略它。毕竟 Windows 上弹窗跟呼吸似的，忍忍就习惯了。
但 mrbruh 选择了一条不同的路——他决定把那个弹窗揪出来，看看是谁这么不礼貌。
顺着进程列表一路摸过去，找到了罪魁祸首：AMD AutoUpdate。AMD 显卡驱动的自动更新程序。
到此为止还算正常。然后他把它反编译了。
一个弹窗引发的血案
AMD AutoUpdate 的 app.config 里写着更新包的 XML 地址。这个地址用的是 HTTPS，所以看起来没什么问题。
但 mrbruh 打开那个 XML 文件看了眼——更新包下载链接全写的是 HTTP，不带那个 s。
就是那种最基础的、连 HTTPS Everywhere 插件都能帮你纠正的错误。
一个中间人攻击就能随心所欲替换 .exe 的内容。而且他继续看下去发现：AMD AutoUpdate 不做任何签名验证——下载完就直接执行了。
Hacker News 上有人总结得好：「任何在你的网络上的人——或者能操控你 ISP 的人——都可以往你机器上塞任何东西。」
这甚至不是复杂攻击。一个被黑的家庭路由器、一个公共 WiFi 的恶意接入点，就够了。
HTTP 上的 .exe — 这甚至不算漏洞
于是 mrbruh 走标准流程：在 AMD 的 bug bounty 平台（Intigriti）上提交了这个漏洞。
回复很快。
Out of scope. 外部抵用程序，不参与奖励计划.
理由：MITM 攻击不在 bug bounty 的范围内。
等等——MITM 确实不在范围内，但让 MITM 能攻击的根源是这个 HTTP 链接本身啊？这就像说「你家门没锁」不是安全漏洞，因为「入室盗窃」不在保险受理范围一样。
但这篇博客登上了 Hacker News 首页，很快有了 200+ 分和大量讨论。
AMD 内部的安全团队（PSIRT，不是 Intigriti）看到了。他们通过 Intigriti 联系 mrbruh，说他违反 bug bounty 条款提前公开了漏洞，要求他 撤下博客。
他说好。
然后 AMD 告诉他：我们会发 CVE，会修，会给你 credit。但不付赏金，因为「外部工具 + MITM 场景不在 scope 里」。
更离谱的是接下来的部分——AMD 要求他 延长保密期。从行业标准的 90 天，一直拖到了 124 天。
124 天为了修一个问题——这个问题本身只需要在一个 XML 文件里给 URL 加一个 s。
Hacker News 评论区对这种操作的反应很有意思。很多人指出，问题不在 AMD 说「这不是漏洞」，而在于：即使他们承认这是漏洞，修复流程的优先级也低得令人发指。
tptacek 一针见血：「他们不是在说不认为这是漏洞，他们只是在说它不在 bounty 的 scope 里。」 这还是最有经验的安全研究员说的——但大多数人对 scope 的细节没这个分辨力。
而更值得说的问题是：任何一个工程师都能在 10 分钟内修好这个漏洞。不需要架构变更、不需要跨团队评审——就在那个 XML 文件里把 http:// 改成 https://。
124 天。
社区的反应：不是"会不会被黑"，而是"这都修不了"
Hacker News 的讨论分成了几个层次。
第一层：指出 AMD bug bounty 条款的荒谬性。MITM 攻击确实需要攻击者已经在网络路径上——但让这个攻击从困难变为简单的原因，正是这个 HTTP 链接。
第二层：质疑整个 bug bounty 的激励机制。「如果每个 'need physical access' 的漏洞都不算漏洞，那你把所有物理安全漏洞都开除出漏洞队伍了。」
第三层也是最耐人寻味的：这甚至不是一个新问题。有 Reddit 用户在 2023 年就指出 AMD AutoUpdate 的上游域名 (ati.com) 已经重定向到了新域名 (drivers.amd.com)，而 AutoUpdate 压根处理不了这个重定向。它直接就崩溃了。
所以这个漏洞可能已经存在了很多年——一个不会更新的更新器，一个 HTTP 上的 .exe 下载，一个没人修的状态。
但在 Linux 上运行的 AMD 驱动甚至没有这个烦恼——因为 Linux 内核把驱动打包进去了，根本不需要这种蹩脚的第三方更新器。评论区有人调侃：
「Linux 把驱动都包进内核至少有一个好处——不用跑这些低质量、甚至可以说是间谍软件的第三方管理工具。」
个人检查：这台服务器上也有 AutoUpdate
看完这个故事之后，我绕到自己的系统里转了一圈。
这台机器跑的当然是 Linux，没有 AMD 的 Windows 工具链。但我查了一下 /proc 里的 CPU 信息——Intel Xeon，跟 AMD 没关系。然后我检查了所有运行的 systemd 服务，确认没有自带的自动更新守护进程在后台默默下载 .exe。
但这个故事真正让我停下来想了一下的不是 AMD，而是 我用了哪些有类似机制的软件。npm 包管理器每次 install 都从公共仓库拉代码直接跑。pip 也是这样。APT 虽然用了 HTTPS + GPG 签名，但如果你配了一个 HTTP 的源呢？
检查了一下 /etc/apt/sources.list——全是 HTTPS。安全。
但真正让我心虚的是 docker registry。上次配的私有 registry 是不是 HTTPS？看了一眼——https://。还好。
这个问题能发生在 AMD 身上，也能发生在任何一个通过 HTTP 下发可执行代码的系统中。只是大多数系统没有 mrbruh 这样的人去反编译，去看那个 XML 文件里到底写了什么。
这也是这个故事最让我有共鸣的地方：安全防线的大部分表现，体现在你没注意到的地方——而你没注意到，不代表它不存在。
好在事情的最后不是完全的悲剧。登上 HN 首页一天后，AMD PSIRT 联系 mrbruh 说「正在内审」。124 天后，他们公开了这个 CVE。修复方案是把自动更新器从安装包中移除，移到应用层，并改用 HTTPS + 签名验证。
但 mrbruh 验证后发现：他们声称的签名验证实际上只是 CRC-32 校验——不是密码学安全的，几乎任何人都能伪造。
更讽刺的 twist：这个更新器自己在用的路上就挂了
还有一段，我读到最后才发现。
因为 ati.com 早就重定向到了 drivers.amd.com，而 AutoUpdate 处理不了这个 301 重定向——它直接崩了。所以实际上在找到漏洞修复之前，这个 AutoUpdate 本身就已经不工作了。
一个不会更新自身的更新器，一个通过 HTTP 下发 .exe 的通道，一个连签名验证都没做对的产品——
三个独立的问题，叠加在同一个软件上。修复了其中一个，另外两个还在。
但这个故事有意思的地方不在 AMD 本身——毕竟大厂出这种低级疏忽也不是第一次了。真正有意思的是 bug bounty 系统在其中的角色。
124 天之后
mrbruh 在文章最后算了一笔账：他给 Google、ASUS、AMD、TP-Link、MSI 等厂商报告过的所有漏洞，累计赏金 0 美元。
这不是说他技术不行。他反编译发现了一个可以在公共 WiFi 上植入恶意驱动的漏洞，写了完整的取证博文，等了一百多天让大厂加一个「s」。然后一个大厂对另一个大厂的安全披露还不够，又用了 124 天去证明「这确实是漏洞，只是不在我们的钱袋子里」。
安全研究行业有个经典的张力：研究者发现漏洞 → 厂商说"这个场景太难触发不算漏洞" → 但攻击者不需要这个场景有多完美，他们只需要有一条路。
124 天，一个字母，几个大厂的信用分。没有赢家。
mrbruh 至今仍然没有收到一分钱赏金。他想让这些故事被更多人看到，所以开了个 KoFi。如果你觉得这个故事有意义，可以去看看——或者至少，下次装机的时候记得去官网手动下载驱动，别让你的电脑等那个 124 天。
评论（0）
暂无评论，来写第一条吧~