CVE-2023-40547 – 避免错误信任 HTTP 头

漏洞与背景

• Bug 出在 shim 的 HTTP 启动代码中：它会根据 Content-Length 头分配缓冲区，但却按实际接收到的 body 长度进行拷贝；如果头部内容是伪造的，就会导致越界写入。
• 这存在于包含 HTTP boot 支持的 shim 构建中；shim 主要用作由 Microsoft 签名的 Secure Boot 加载器，然后通过 Machine Owner Keys (MOK) 强制执行自己的策略。
• 先前暗示“每一个 Linux bootloader”都会受影响的说法已被更正：这是一个 shim 的 bug，大约在 8 年前引入。

攻击面与严重性

• 并不限于显式的 HTTP boot：
  • 本地：有权限的恶意软件可以覆盖 EFI System Partition 或 EFI 变量，并强制使用 HTTP boot，或者通过 HTTP 链式加载 shim→GRUB2→shim。
  • 相邻网络：PXE boot 加上 MITM 可以串联为通过 HTTP 加载 shim。
  • 远程：对使用 HTTP boot 的受害者进行 HTTP boot 场景下的 MITM。
• 有人认为，一旦攻击者能够修改 EFI 变量/ESP，其他攻击（例如添加 MOK、使用更旧的已签名二进制）本来就已经可行；也有人反驳说，Secure Boot 的目标恰恰就是要抵御这类篡改。
• 对“Critical”评级存在分歧：有人认为这是必要的纵深防御，另一些人则觉得如果服务器或本地系统已经严重被攻破，这个评级就没那么有意义。

HTTP 与 HTTPS 以及实现细节

• HTTPS 并不能阻止恶意服务器；它主要是阻止 MITM。
• 几位评论者指出，UEFI/boot 代码可能会跳过正确的 HTTPS 证书验证（CA 存储大小、更新与吊销复杂性、时间偏差等），使得即便在 HTTPS 上 MITM 也仍然现实可行。
• 关于 HTTP 语义存在争论：在 HTTP/1.1 中，Content-Length 本应具有权威性；如果实现改为信任某个单独测量的“bodyLength”，则两者必须小心协调——这种不匹配最终导致了这个 bug。

Shim、Secure Boot、MOK 与吊销

• 常见用法是本地磁盘上的 shim → GRUB → kernel；HTTP boot 比较小众，但确实存在。
• Shim 会使用自己的 MOK 列表验证下一阶段二进制；通过 UEFI DBX 进行 Secure Boot 吊销可以使存在漏洞的 shim 二进制失效，但许多系统很可能从未更新过 DBX。
• 从原理上说，measured boot 和 TPM 可以把磁盘解密密钥绑定到特定的启动组件，但这被认为很复杂，而且典型用户很少使用。

GPLv3、反 tivoization，以及 Microsoft 的签名政策

• 一个很大的分支讨论的是为什么 Microsoft 避免给像 GRUB 这样的 GPLv3 bootloader 签名：
  • 有人引用 GPLv3 的 “Installation Information” 条款：包含 GPLv3 组件的设备分发者必须提供用户在该设备上安装和运行修改版所需的任何方法/授权密钥。
  • 一开始有人怀疑这是否适用于签名密钥，但后来承认，“authorization keys” 这一措辞以及 FSF 对 anti‑tivoization 的评论支持这种解释。
  • 也有人认为，让用户注册自己的密钥（而不是提供厂商私钥）就应该足以满足许可证要求，并指出阻止用户密钥的不良 Secure Boot 实现才是真问题。
  • 还有关于签名是否与版权相关、以及仅仅签名一个二进制文件（而不分发它）是否会触发 GPL 义务的争论；观点彼此冲突，而法律状态仍被描述为不确定。
• Shim 采用 MIT 许可证以规避 GPLv3 约束，从而可以被 Microsoft 签名，同时由它自己执行信任策略（MOK）。

对 Secure Boot 和生态的看法

• 有些人认为 Secure Boot 是有效的纵深防御，尤其能抵御针对未加密 ESP 的 “evil maid” 攻击，并主张厂商应该允许用户控制密钥。
• 另一些人则非常批评：
  • 他们认为 Secure Boot 主要是在巩固厂商控制权（尤其是 Microsoft 的默认密钥），更像 DRM 而不是用户安全。
  • 他们举出一些无法关闭 Secure Boot 或无法添加用户密钥的设备，以及启用 Secure Boot 会带来可用性问题（例如休眠、“吓人”的警告、Linux 摩擦）。
  • 他们担心 PC 平台正在走向围墙花园，并将其类比为早期的反垄断问题。

网络启动与设计选择

• 多人把 HTTP/PXE boot 描述为“安全噩梦”或至少是高风险，不过也有人指出它们在实验室测试和部署中很有用。
• 有人质疑 shim 为什么要直接实现 HTTP boot，而不是委托给一个独立的、由 MOK 签名的 EFI 二进制文件。
• 还有评论批评这样一个显而易见的头部信任 bug 不应该通过代码审查，把它比作初学者错误，并顺带提到补丁中的一些小清理（例如修复拼写错误）。