UEFI 固件中的代码执行漏洞威胁地球上大多数服务器

利用条件与威胁模型

• 漏洞位于 UEFI 网络启动栈（PXE / ICMP 处理）。
• 利用需要：
  • 启用并实际使用 PXE 或网络启动。
  • 能够向客户端的 IP 发送精心构造的单播 ICMP 错误。
  • 在早期启动阶段具备网络可达性，通常位于管理网络或内部网络上。
• 有人认为这主要只会让内部人员、民族国家或已经在内部网络中站稳脚跟的攻击者受益。
• 也有人强调这仍然很严重，因为许多环境共享管理网络，而且可能不会严格过滤 ICMP。

对 Secure Boot 和磁盘加密的影响

• 固件中的代码执行可以：
  • 绕过度量启动并破坏证明（attestation）。
  • 破坏那些在 PXE 启动机器接收密钥之前先进行状态证明的工作流。
  • 作为 BitLocker / 基于 TPM 的磁盘加密绕过，尤其是在未使用口令的情况下。
• 即使有口令，固件被攻陷也可能为暴力破解创造条件。

PXE / 网络启动有多常见？

• 观点不一：
  • 有人称 PXE 很“小众”且脆弱；许多服务器从本地介质启动，而且很少重启。
  • 也有人说，在服务器、裸机托管集群、瘦客户端以及前公司桌面上，PXE/网启“极其常见”。
• 令人担忧的是，许多设备默认启用了 PXE，即使它在启动顺序中排得很后。

可利用性细节与缓解措施

• 攻击者可以向网络中大量投放恶意 ICMP，然后等待重启；如果能持续发送，就不必精确卡住单个报文的时机。
• 主机防火墙在固件启动期间无能为力；过滤必须在交换机/防火墙处进行，或者依赖独立的管理网络。
• 划分良好的管理网络和严格的 ICMP 过滤会显著提高攻击门槛。
• 个人设备：
  • 如果启用了 UEFI 网络启动并且可达，它们理论上也有风险。
  • 有评论称消费级设备通常会禁用 PXE；也有人说自己经常见到它处于启用状态。

UEFI 设计与固件复杂性

• 对 UEFI 的强烈批评：
  • 被视为“操作系统规模”、过度复杂，而且不可避免地容易出错。
  • 怀疑这种复杂性与简洁的 BIOS 风格代码相比根本没有必要。
• 对 UEFI 的辩护：
  • 它提供标准化接口（存储、网络、帧缓冲、ACPI/device trees），使通用 OS 引导能够跨多样硬件实现。
  • 被认为比许多临时拼凑的 ARM/SBC 启动链更好。
• 更广泛的主题是受信任代码中的“少即是多”：
  • 例如，用数百行左右的专用汇编替换上百万行的通用固件。
  • 呼吁尽量减少攻击面、依赖项和运行时复杂性（微内核、像 seL4 这样的形式化验证内核、更简单的固件）。

systemd、依赖关系与 Unix 哲学

• 一个子线程借此事件批评庞大、快速演进的代码库（例如 systemd）与小而稳定的代码库（例如经典 init）之间的对比。
• 反驳意见是：systemd 取代了许多分散的脚本和守护进程，并且有些人报告它极其可靠。
• 普遍共识是，依赖蔓延和巨大的攻击面使得“给地球打补丁”越来越难以为继。

严重性评分与媒体表述

• 有人认为标题（“威胁地球上大多数服务器”）带有制造恐慌的意味，尤其考虑到前置条件。
• 也有人认为它仍然值得关注，因为在现实场景中它可以实现权限提升和绕过证明。
• 关于 CVSS 的讨论：
  • 将其与近期的 PHP 漏洞作比较；困惑为何这项评分是 9.5，而 PHP 的是 9.2。
  • 解释说 CVSS 由具体向量（网络 vs 相邻、复杂度等）决定，而且并不完美，高分还会带来扭曲的激励。
  • 几条评论说 CVSS 数字经常具有误导性，不应过度解读。

AI、后门与披露

• 多条评论指出，LLM 让在大型代码库中寻找漏洞变得廉价，从而压垮了“发现并修补”的模式。
• 有人推测 AI 也会暴露此前隐藏的或故意设置的后门；也有人说，如今越来越难区分 bug 和后门。
• 对“协调披露”时间表感到沮丧；认为一旦 AI 工具广泛普及，早期保密可能并不现实。

终端用户与云端担忧

• 对普通个人 PC：
  • 风险取决于 PXE 是否启用，以及是否可从恶意网络访问。
  • 很多用户可能会通过大量依赖 PXE 和 UEFI 的云服务商与托管公司间接受影响。
• 特别令人担心的是：
  • 裸机托管服务商和共享数据中心。
  • 如果 PXE 配置错误但仍启用，企业笔记本和“锁定”设备也会受影响。