UEFI 固件中的代码执行漏洞影响全球大多数服务器

# UEFI 固件中惊现代码执行漏洞，全球绝大多数服务器受到威胁 来源：https://arstechnica.com/security/2026/10/code-execution-flig-in-uefi-firmware-threatens-most-servers-on-planet-earth/ **打破信任链** EDK2 中发现严重漏洞，攻击者可在启动流程极早期执行代码。 全球安全防御者又要面对又一个因披露不当而引爆的代码执行漏洞，这一次出问题的是全球大多数服务器厂商和数据中心都在使用的启动阶段固件。 该漏洞严重评分为 9.5/10，存在于 TianoCore EDK II (https://www.tianocore.org/tianocore-wiki.github.io/reference/external-resources/edk_ii.html) 中——这是一个开源代码库，硬件厂商和云服务商用它来构建在启动序列中运行的 UEFI 固件。去年，UEFI 论坛的一位代表称 EDK2 是"UEFI 规范的首选解决方案/实现"。几乎所有 UEFI 供应商（有时仍称为 IBV，即独立 BIOS 厂商），包括 AMI、Insyde 和 Phoenix，都在大量使用这份参考代码。微软的加固版 EDK2 分支项目 Project Mu 同样使用了包含该漏洞组件的代码。 该漏洞编号为 CVE-2026-97631，是 ICMP (https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol) 组件中的一处内存损坏缺陷。攻击者可以利用它执行恶意代码，其执行时机早于操作系统和固件实施 Secure Boot (https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2019.pdf) 等防御措施的时刻——Secure Boot 为包括可信平台模块 (Trusted Platform Module) (https://www.trustedcomputinggroup.org/work-groups/tpm)（TPM）在内的所有启动阶段加载代码建立信任链。虽然 CVE-2026-97631 交付的最终载荷不具备持久性（即仅运行一次），但它能给攻击者打开一扇大门，让他们安装其他同样在启动流程极早期执行的载荷。 ## 木已成舟 发现 CVE-2026-97631 的研究人员——来自 Anthropic 的 Alex Matrosov 和来自 Google 的 Dan Holmes——原本安排将漏洞保密，直至一月的协调披露日期。然而，主板及其他硬件制造商 AMI 上月发布了一篇 pull request (https://github.com/tianocore/edk2/pull/13200)，详细描述了该漏洞并附上了修复代码。该帖子引起发现者关注后，TianoCore 项目成员上周发布了一份公开安全公告 (https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m)。 由于补丁代码已公开，高级黑客轻而易举就能了解漏洞的触发机制并编写出可用的利用工具。更令人紧迫的是，在数百万台已售出或在用的终端设备上修补 UEFI 代码漏洞本身就是一项繁重而耗时的工作，而这些设备涉及数千家硬件厂商和云服务商。此次漏洞消息传出的六天前，另一起披露不当事件刚刚发生——那是 PHP 编程语言中的一个关键代码执行漏洞 (https://arstechnica.com/security/2026/10/php-maintainers-tell-web-devs-to-prepare-themselves-for-critical-security-patches/)。 "EDK2 网络栈 ICMP 解析器中的这个漏洞，从它如何影响信任链和更广泛生态系统的角度来看非常有意思，"安全公司 Dragos 首席研究官、Metasploit 的创建者 HD Moore 表示。"一个意图入侵附近终端设备或服务器的攻击者，可以利用这个 bug 在启动流程仍能访问敏感组件（例如终端设备的 TPM）的时机劫持程序执行流。这可以被用来破解磁盘加密——适用于攻击者拥有短期网络访问权限的场景（而在设备被窃取的场景下则更为容易）。" CVE-2026-97631 是 PXE-Base Code 驱动程序（NetworkPkg/UefiPxeBcDxe）中一处存在了 16 年的缓冲区溢出漏洞。该驱动负责允许服务器、存储设备及其他设备通过从本地网络下载的代码进行启动。在这一过程——即预执行环境启动——中，驱动程序使用网络监听器监控 ICMP 错误。由于驱动未强制执行 504 字节的内存拷贝上限，导致相邻数据被覆写，恶意内部人员或已获得本地网络低级访问权限的黑客便可以发送一条错误消息，将代码追加到该限制之外。运行在 CPU 上的 UEFI 模块随即被破坏。 正如官方公告所述： > 在网络启动过程中，PXE Base Code 驱动（NetworkPkg/UefiPxeBcDxe）会保持一个用于接收 ICMP 错误消息的开放请求，并将每条接收到的消息拷贝到其私有上下文结构中固定 504 字节的字段 Mode.IcmpError 中。拷贝循环的边界处理在 IPv4 和 IPv6 处理器（PxeBcIcmpErrorDpcHandle 和 PxeBcIcmp6ErrorDpcHandle）中均不正确：对于超过 504 字节的消息，它仍会拷贝字节到该字段中，并且它以累计长度而非每片段长度推进目标指针，因此超长消息会将攻击者控制的字节写入该字段之外。接收路径上的前序环节均未对消息长度进行限制。 恶意错误消息可以通过简单的单播数据包发送，从任何网络距离抵达目标设备的 IP 地址，只需在 PXE 启动序列期间发送即可。攻击者还可以通过让启动序列挂起来实施拒绝服务。当攻击者知晓目标固件的构建版本时，便可以植入一个"伪造事件"，在 CPU 的 UEFI 固件环境中执行恶意代码。该代码运行在 ring 0——CPU 的最高特权执行级别。由于这些利用方式能够绕过旨在通过密码学方式向远程服务器证明硬件安全性的证明流程，它们为提升有限权限提供了重要机会。 ## 又一个"永恒漏洞" CVE-2026-97631 加入了 UEFI 或与其密切相关的代码中此前发现的大量漏洞之列。其中最为严重的是 LogoFail (https://arstechnica.com/security/2023/12/just-about-every-windows-and-linux-device-vulnerable-to-new-logofail-firmware-attack/)，其根源是几乎所有硬件厂商的 UEFI 中都包含的 Logo 图像。渲染 bug 允许攻击者颠覆 UEFI 强制执行的信任链，并在操作系统加载或 Secure Boot 运行之前安装恶意组件。PixieFail (https://arstechnica.com/security/2024/01/new-uefi-vulnerabilities-send-firmware-devs-across-an-entire-ecosystem-scrambling/) 是与 CVE-2026-97631 类似的漏洞——同样源于 EDK2 中的 PXE 启动缺陷。在发现该漏洞之后，研究人员开展了多项 (https://introspector.oss-fuzz.com/project-profile?project=edk2) 模糊测试 (https://www.ndss-symposium.org/wp-content/uploads/2025-400-paper.pdf) 项目 (https://github.com/google/oss-fuzz/tree/master/projects/edk2)，旨在挖掘该开源代码库中的其他关键缺陷。但看来这些努力未能发现这个最新漏洞。 其他近期发现的 UEFI 漏洞包括： - PKFail (https://arstechnica.com/security/2024/09/secure-boot-neutering-pkfail-debacle-is-more-prevalent-than-anyone-knew/)，一个供应链事故——非生产测试平台密钥被用于数百款设备型号，这些密钥在被发现之前已公开超过十年 - BootHole (https://arstechnica.com/information-technology/2020/07/new-flaw-neuters-secure-boot-but-theres-no-reason-to-panic-heres-why/) - Bootkit (https://arstechnica.com/security/2024/11/found-in-the-wild-the-worlds-first-unkillable-uefi-bootkit-for-linux/) - BlackLotus (https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/) 与 CVE-2026-97631 一样，利用这些载荷极具吸引力，因为它们允许攻击者在启动流程的极早期感染机器——在 TPM 及其他防御机制加载之前——从而造成最大破坏。鉴于 CVE-2026-97631 的无处不在，Moore 表示它很可能成为一个"永恒"漏洞，在已停止支持的系统上长期存留。 利用这个最新漏洞也有重要的注意事项和限制条件。如上所述，对本地网络的某种程度的控制是前提条件。这很可能将利用场景限制在内部人士，或者成功在网络内部获取低级访问权限并寻求提升系统权限的攻击者（如民族国家或勒索软件团伙）。目前尚无证据表明 CVE-2026-97631 能提供网络的初始入口点。还有其他障碍需要跨越。 "就利用该漏洞本身而言，攻击者需要猜测目标系统内的特定地址，所以这不是你可以用单一利用代码针对任何目标就能在多种不同设备上获得 RCE 的情况，而需要针对每个目标型号/版本/配置进行调整，因为地址会因这些因素而变化，"固件安全公司 Eclypsium 的首席研究员 Jesse Michael 告诉 Ars。"与 BootHole、BlackLotus 和 Baton Drop 等之前的一些高知名度漏洞不同，这个漏洞可以通过一个基本的代码修复来解决，只需要部署 BIOS/UEFI 更新，而不需要处理吊销、pk/kek/db/dbx 密钥管理更新，也不需要像修复引导加载程序中的 Secure Boot 绕过那样确保更新操作系统和供应介质。" CVE-2026-97631 不影响家庭和小型办公室用户，也不影响任何仅从磁盘驱动器启动设备的用户。它只适用于拥有从本地网络（或可设想从 Internet 连接资源）启动的机器的组织。即便如此，目标固件还必须基于 EDK2 构建（而非其他参考实现），并且使用了 PXE 功能（该功能默认开启）。 Intel 在一封邮件中表示，据其所知，其"目前处于安全支持范围内的商业产品"均未受到影响。"Intel 的参考代码中不包含受影响的 EDK2 功能，不过该功能可能已被 OEM 板卡供应商或系统制造商集成，"该公司补充道。Intel 建议客户向其系统制造商咨询具体指导。然而，公开可用的 Intel 参考代码 (https://github.com/intel/FSP) 中确实提到了 EDK2。此外，TianoCore 曾表示 (https://www.tianocore.org/tianocore-wiki.github.io/reference/faqs-glossaries/differences_between_udk_and_edk_ii.html)，Intel 提供的每套 UEFI 开发套件"都是针对 EDK II 源代码的某个特定版本完全验证过的实现"。Intel 的许多其他文档同样引用了 EDK2。 Arm 在回复一系列问题时表示："CVE-2026-97631 不直接适用于 Arm 的产品组合。"与 Intel 类似，Arm 发布的固件 (https://github.com/ARM-software/arm-systemready/blob/main/SystemReady-band/README.md) 同样大量借鉴了 EDK2。TianoCore 也已记录了 (https://github.com/tianocore/edk2-platforms/blob/master/Platform/ARM/Readme.md) Arm 对 EDK2 的依赖。 虽然部分平台可能不含 EDK2 代码，但所有服务器用户都应审慎排查 CVE-2026-97631 是否影响自身。 在本文发布时尚未得到回复的问题包括发送给 AMD、Phoenix Technologies、AMI、Microsoft 和 Amazon 的问询——这几家很可能都是受此影响最大的其他组织。在没有获得这些组织是否使用 EDK2 的确切答案之前，无法说明哪些设备受到了影响、受到了何种影响，以及这些组织或其用户是否需要采取行动。TianoCore 项目的代表也未予回应。 部分读者可能会对信息不够详尽感到不满。有时——尤其是在保密期限提前数月就被打破的披露不当事件中——初期报道确实难免缺少可操作的具体信息。 受影响用户应与为其系统提供启动固件的制造商联系并寻求指导。除此之外，如果条件允许，还应考虑至少暂时关闭网络启动功能。固件配置应始终启用 TPM 和 Secure Boot 等安全功能——尽管这些防御措施无法抵御此次的特定威胁。同时，建议监控日志以发现利用尝试的迹象。 Dan Goodin 的照片 (https://arstechnica.com/author/dan-goodin/) Dan Goodin 是 Ars Technica 的高级安全编辑，负责监督恶意软件、计算机间谍活动、僵尸网络、硬件黑客、加密和密码等方面的报道。业余时间他喜欢园艺、烹饪和关注独立音乐圈。Dan 常驻旧金山。在 Mastodon 上关注他：here (https://infosec.exchange/@dangoodin)，在 Bluesky 上关注他：here (https://bsky.social/profile/dangoodin.bsky.social)。通过 Signal 联系他：DanArs.82。 37 条评论 (https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/#comments)