2026-11-02 14:55:55 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

潜伏16年的UEFI漏洞：开机那几秒，你的所有防线都还没上线

原创

欢迎关注→
欢迎关注→

安全客

2026年11月2日 08:30
北京

去阅读

CVE-2026-97631，CVSS 9.5，在Secure Boot加载之前就能执行代码，攻击窗口只有开机那几秒。

做等保测评的朋友应该都遇到过这个场景：客户问\"我们上了Secure Boot，还上了TPM，硬盘也加密了，服务器被偷了数据也读不出来吧\"。

上周之前，这个回答是可以给的。

10月22日，TianoCore发了安全公告GHSA-99cj-7hg9-mp4m。CVE-2026-97631，CVSS 4.0评分9.5。漏洞在EDK II的PXE网络启动驱动里，位置是NetworkPkg/UefiPxeBcDxe。攻击者可以在操作系统加载之前、在Secure Boot和度量启动做完校验之前，让代码在ring 0跑起来。

这段代码的年龄，按提交记录往前追，大概16年。

一、504字节的缓冲区，和一个算错的指针

漏洞本身不复杂，复杂的是它藏在哪。

PXE网络启动的时候，UefiPxeBcDxe驱动会挂一个接收请求，专门等着收ICMP差错报文——就是路由器告诉你\"这个包送不到\"的那类消息。每收到一个报文，驱动就把它拷进自己私有上下文结构里的Mode.IcmpError字段，这个字段固定504字节。

问题出在拷贝循环的边界处理上。IPv4的PxeBcIcmpErrorDpcHandle和IPv6的PxeBcIcmp6ErrorDpcHandle两个handler都写错了。报文长度超过504字节的时候，循环还在往里拷；而且目标指针是按累计长度推进的，不是按每个分片的长度推进。结果是超长报文把攻击者控制的数据写到了字段之外的相邻内存里。

接收路径上，前面没有任何地方限制报文长度。

官方公告的原话是\"the copy loop's bounds handling is incorrect in both the IPv4 and IPv6 handlers\"，两个handler都中招，等于IPv4和IPv6双通道都能触发。

利用方式听起来很简单：从任意网络位置发一个单播报文到目标设备的IP地址，只要发在PXE启动序列的那个窗口里。不需要密码，不需要已有的访问权限，只要求一件事——目标得正在用PXE网络启动。

二、为什么这个洞比一般的RCE更麻烦

一般的内存破坏漏洞，你在操作系统里打补丁，重启，完事。

这个洞的代码跑在操作系统之前。

攻击者能做到两件事。轻的一件是拒绝服务：让启动过程卡死在那个阶段。听起来不严重，但对无人值守的机房来说，一台机器卡在PXE阶段反复重启，运维半夜得跑一趟。

重的一件才是真正的问题。如果攻击者知道目标固件的具体build，他可以在UEFI固件环境里\"种一个伪造事件\"，让恶意代码在CPU的ring 0执行。ring 0是最高的特权级，比操作系统内核还靠下。

在这个位置上，攻击者能碰到TPM。

Metasploit的作者、现在在Dragos做首席研究官的HD Moore说得挺直白：攻击者可以用这个bug在一个\"启动过程仍然能访问TPM这类敏感组件\"的时间点上劫持程序流，\"在攻击者拥有短期网络访问权限的情况下，这可能被用来破解磁盘加密（在设备被盗场景里就更简单了）\"。

这句话的分量在于：全盘加密的信任根在TPM，TPM的信任根在启动链，启动链的第一环就是固件。固件被拿下了，底下所有东西的保证都变成了假设。

更麻烦的是attestation。远程证明机制的作用是向服务器证明\"这台硬件是干净的\"，验的就是启动链的度量值。这条链在上游就被污染了，证明依然能通过。

固件安全厂商Eclypsium的首席研究员Jesse Michael补充了一个技术细节：利用这个漏洞需要猜目标系统里的具体地址，所以不是\"一个exploit到处扔\"，得针对每个目标型号、版本、配置单独调。

这个限制听起来降低了风险，但反过来看，它把攻击者筛成了有耐心的那一类。国家级行为体、勒索团伙、或者已经拿到内网低权限正在找提权路径的人，这三类都不缺耐心。

三、漏洞是怎么漏出来的：又一次提前泄密

这部分单说，因为它解释了为什么现在这么被动。

发现漏洞的是两个人：Anthropic的Alex Matrosov和Google的Dan Holmes。他们本来安排的是2027年1月做协调披露。

上个月，主板厂商AMI往edk2仓库提了一个pull request（#13200），里面详细描述了漏洞，还附了修复代码。这个PR是公开的。

发现者看到之后，TianoCore项目成员上周就发了公告。

于是披露时间从明年1月，提前到了10月22日。修复代码已经在GitHub上公开，任何有能力的攻击者都能读到触发条件，反推出可用的利用。

这和六天前PHP2Shell的情况几乎是同一个剧本。那次的细节是10月20日在Hacker News泄露，PHP官方被迫把发布计划提前一天。

Ars Technica在报道里用了一个词——\"another botched disclosure\"，又一次搞砸的披露。两次事件相隔六天，两次都是补丁代码先走漏，两次都是防守方被迫在还没准备好的时候应对。

这里有个结构性问题：开源项目的修复走PR流程，PR是公开的。厂商内部的安全团队和开源社区之间的披露协调，中间缺少一个\"补丁先合、公告后发\"的机制。这次AMI提PR可能只是为了推进修复，但它客观上把整个生态的披露时间表打乱了。

四、影响面：几乎所有服务器都沾边

EDK II是什么地位？UEFI论坛去年在一份材料里直接称它为\"UEFI规范的卓越解决方案/实现\"。

几乎所有的UEFI供应商——业内有时叫IBV，独立BIOS厂商——包括AMI、Insyde、Phoenix，都大量使用这份参考代码。微软的Project Mu，那个号称加固过的EDK2分支，也用了包含这个漏洞组件的代码。

受影响版本是edk2-stable202608及更早，且没有打上patch #13302的。

Red Hat的安全公告显示RHEL 8、9、10里的edk2包都被列为受影响。TianoCore在10月15日已经把修复合并到上游主分支，但到目前还没进稳定版本。

这里要区分两件事。

Intel的回应是：目前\"在安全支持期内的商业产品\"没有已知受影响的。理由是Intel的参考代码里不包含这块受影响的EDK2功能。但它也补了一句，\"OEM板卡厂商或系统集成商可能会集成\"。而且公开的Intel参考代码（FSP）里是有EDK2引用的。TianoCore自己也说过，Intel提供的每个UEFI开发套件\"都是针对特定EDK II源码修订的完整验证实现\"。

Arm的回应更简短：\"CVE-2026-97631不直接适用于Arm的产品组合。\"但Arm公开的SystemReady固件同样大量借用EDK2，TianoCore的文档里也记录了Arm对EDK2的依赖。

AMD、Phoenix、AMI、微软、亚马逊——报道发出时都没回复。

这个局面落到运维头上就一句话：得自己去问服务器厂商。