Codex发现一个隐藏的HTTP/2炸弹

# Codex 发现了一个隐藏的 HTTP/2 炸弹 来源：https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb 我们发布了 HTTP/2 炸弹，一种针对大多数主流 Web 服务器的远程拒绝服务漏洞，包括： - nginx - Apache httpd - Microsoft IIS - Envoy - Cloudflare Pingora 这些服务器的默认 HTTP/2 配置均存在该易受攻击的行为。 该攻击由 Codex 发现，它链式结合了人类已知长达十年的两种技术：压缩炸弹和 Slowloris 式保持。炸弹针对 HTTP/2 的标头压缩方案 HPACK：线缆上的一个字节会变成服务器上的一次完整标头分配，且每个请求中重复数千次。保持则是通过零字节的流控制窗口，阻止服务器释放任何已分配的内存。 在 Shodan 上的一个好奇搜索揭示了超过 880,000 个支持 HTTP/2 并运行这些服务器的网站（https://www.shodan.io/search?query=ssl.alpn%3A%22h2%22+product%3Anginx%2CApache%2CIIS%2CEnvoy%2CPingora），尽管许多网站位于 CDN 之后，这使得攻击更难奏效。 一台拥有 100Mbps 连接的普通电脑可以在数秒内使易受攻击的服务器不可用。针对 Apache httpd 和 Envoy，单个客户端在大约 20 秒内即可占用并持有 32GB 的服务器内存。 [](https://substackcdn.com/image/fetch/$s_!b5uX!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5ca91bca-3d08-428c-aed2-64a4b18bdd63_1920x1080.gif) *顺时针方向从左上方开始：Apache httpd, Envoy, nginx, Microsoft IIS。 (2 倍播放速度)* - Quang Luong 发现了该漏洞。他将在今年六月于斯坦福大学举办的即将举行的“真实世界 AI 安全”（https://seclab.stanford.edu/RealWorldAIsec/）会议上展示他的技术。 - Jun Rong 和 Duc Phan 确认了该攻击在其他 Web 服务器上的有效性。 HPACK（RFC 7541 (https://www.rfc-editor.org/rfc/rfc7541)）是一种有状态压缩方案。HTTP/2 连接的每一方都维护一个近期见过的标头动态表。发送方可以将一个标头插入表中一次，然后在后续请求中通过索引（通常是一个字节）来引用它。接收方查找索引，并在它正在组装的请求中生成完整的标头副本。 HTTP/2 本身（RFC 9113 (https://www.rfc-editor.org/rfc/rfc9113)）增加了逐流流控制：接收方通告一个窗口，发送方在收到 `WINDOW_UPDATE` 之前不能发送超出该窗口的 DATA 帧。关键是，客户端控制服务器响应的窗口。 每个特性都有已知的滥用模式，而该漏洞将它们链式组合： - **HPACK 索引引用炸弹**：在动态表中植入一个标头，然后发出数千个 1 字节的索引引用来指向它。每个引用对攻击者来说是一个线缆字节，而对服务器来说则是大约 70 字节（nginx, IIS, Pingora）到大约 4000 字节（Apache httpd, Envoy）的分配。 - **HTTP/2 窗口阻塞**：通告一个零字节的流控制窗口，使服务器永远无法完成响应发送，然后滴入 1 字节的 `WINDOW_UPDATE` 帧来不断重置发送超时，从而将所有分配的内存固定在内存中，直到服务器的超时时间结束。 这些都不是全新的。Cory Benfield 在 2016 年创造了“HPACK Bomb”一词，对应 CVE-2016-6581 (https://nvd.nist.gov/vuln/detail/CVE-2016-6581)；2025 年，Gal Bar Nahum 在 Apache httpd (https://galbarnahum.com/posts/apache-httpd-cve-2025-53020) 上实现了约 4000 倍的放大效果，对应 CVE-2025-53020（修复说明 (https://eissing.org/icing/posts/hpack-bombing-apache/)）。没有压缩放大器参与的 HTTP/2 Slowloris 式资源耗尽攻击同样历史悠久：针对无限制 CONTINUATION 帧的 CVE-2016-8740 (https://www.cve.org/CVERecord?id=CVE-2016-8740) 和针对 Apache httpd 工作线程饥饿的 CVE-2016-1546 (https://www.cve.org/CVERecord?id=CVE-2016-1546)。 这里的创新之处在于放大的来源。经典的炸弹是将一个大值放入表中并重复引用它，因此服务器学会了限制解码后标头的总大小。我们的变体则反其道而行之：标头几乎是空的，放大效果来自服务器围绕它分配的每个条目的记账开销。解码大小限制永远不会触发，因为几乎没有什么需要解码。 对于限制标头字段数量而非大小的服务器（Apache, Envoy），`Cookie` 是绕过点：RFC 9113 §8.2.3 (https://www.rfc-editor.org/rfc/rfc9113#section-8.2.3) 明确允许将 Cookie 标头按“碎片”（crumb）拆分成多个字段，而这些服务器不将这些碎片计入限制。由此产生的放大效果取决于服务器如何重组 cookie。Envoy 将每个碎片追加到一个缓冲区中，因此一个 4 KB 的 cookie 值被引用 32000 次，理论上产生约 3600:1 的放大比例（最终 cookie 字节数相对于线缆字节数）；实测的 RSS 比例更高：跨流约为 3800:1，在单个流上由于分配器开销叠加可达约 5700:1。Apache httpd 在每次追加碎片时重建整个合并后的字符串，旧副本在流清理之前一直存活，因此即使是一个空 cookie 也能产生约 4000:1 的放大。 在真实攻击中，你可能不希望进程直接 OOM（内存溢出），因为被杀死的 worker 会重新启动并清理内存。更有效的做法是将内存压力控制在杀死阈值之下，迫使机器使用交换分区，从而拖慢该机器上的每一个其他请求。 针对各个服务器的 AI 生成的技术分析、Docker 实验环境以及 PoC 脚本可以在此处找到 (https://github.com/califio/publications/tree/main/MADBugs/http2-bomb)。 请不要将这些用于你不拥有的基础设施。 我们已于四月向 nginx 披露了此问题。他们的回应是引入了 `max_headers` 指令 (https://github.com/nginx/nginx/commit/365694160a85229a7cb006738de9260d49ff5fa2)（来自 freenginx），并在第二天将其发布在 1.29.8 版本中。至此，我们认为该攻击已公开。 我们于五月二十七日向 Apache 披露，Stefan Eissing 在同一天修复了此问题 (https://github.com/apache/httpd/commit/47d3100b252dc6668a9e46ae885242be9eeca9cd)，方法是让 `cookie` 标头计入 `LimitRequestFields` 的限制。该问题被分配了 CVE-2026-49975。 上述修复提交是公开的，并直接披露了攻击向量；任何有能力的 AI 模型都可以将这些差异转化为可用的漏洞利用代码，这正是我们发现 Microsoft IIS、Envoy 和 Pingora 也存在此漏洞的方式。我们已经通知了它们的维护者。鉴于现在从提交到实现漏洞利用的路径非常短，我们发布此技术文章以便用户采取以下缓解措施。 **nginx**：升级到 1.29.8+ 版本，该版本增加了 `max_headers` 指令，默认值为 1000。如果无法升级，请使用 `http2 off;` 禁用 HTTP/2。 **Apache httpd**：修复代码位于 mod_http2 v2.0.41 中，可从独立的 mod_http2 发布页面 (https://github.com/icing/mod_h2/releases) 以及 httpd 主线版本中获取，但尚未包含在 2.4.x 版本中。如果无法升级，请设置 `Protocols http/1.1` 以禁用 HTTP/2。降低 `LimitRequestFieldSize` 可以缩小每个流的破坏半径（它限制了合并后的 cookie，从而限制了碎片数量），但这只是一种部分缓解措施，因为攻击者仍然可以在多个流和连接上放大效果。降低 `LimitRequestFields` 在此处无效：重复的 cookie 碎片不会计入该限制。 **Microsoft IIS, Envoy, Cloudflare Pingora**：在撰写本文时尚未提供补丁。如果可能，请禁用 HTTP/2，或者在前端放置一个对每个请求的标头数量实施硬性限制的代理。 **通用建议**：“最大解码后标头大小”和“最大标头数量”是两个不同的限制，服务器需要同时具备两者。任何 HTTP/2 终止点都应该限制每个请求的标头字段数量，包括 `cookie` 碎片，而不依赖于它们的总大小；并且无论 `WINDOW_UPDATE` 活动如何，都应该限制挂起流的生命周期。如果目前无法做到以上任何一点：请将每个 worker 的内存限制（cgroups、`ulimit -v`、容器限制）设置得足够紧，使被炸弹攻击的 worker 被 OOM 杀死并重新启动，从而在拖垮整个机器进入交换分区之前解决问题。一个 worker 进程很少需要 GB 级别的内存；让内核提前杀死一个 worker 是一种比让攻击者将整台机器保持在 95% 内存占用更优的失效模式。 RFC 7541 有一个完整的章节讨论这一威胁。§7.3 内存消耗 (https://datatracker.ietf.org/doc/html/rfc7541#section-7.3) 开头写道：“攻击者可以尝试使一端耗尽内存”，然后解释了 HPACK 通过 `SETTINGS_HEADER_TABLE_SIZE` 限制动态表，并认为问题已解决。但是，当五个独立的实现都阅读了该章节却仍然交付了同一类缺陷时，问题出在规范本身。 更深层的欠缺在于，规范将内存风险纯粹定义为放大比率，但比率只是等式的一半。如果请求完成后内存被释放，那么 70:1 的放大是无害的。它之所以成为攻击，是因为 HTTP/2 允许客户端几乎免费地保持连接打开，从而使每一个已分配的字节都可以被长期固定。 另外值得注意的是这个漏洞是如何被发现的。这两部分技术已经公开了十年。Codex 所做的是阅读代码库，识别出这两个部分可以组合，并构建了组合攻击。这个组合一旦看到就显而易见，但据我们所知，之前没有人针对这些服务器将其整合起来。 当团队向我展示这项研究时，我仿佛回到了 2012 年。那一年，Juliano Rizzo 和我发现了 CRIME (https://en.wikipedia.org/wiki/CRIME)，一种通过压缩后的 HTTP 标头恢复 cookie 的压缩预言机。当时我在 Google，因此被要求审查修复方案，该方案后来成为了 HPACK。我刚刚重新读了我当时审查的笔记：我从未考虑过这种攻击。我过于专注于对抗 CRIME，而错过了炸弹。 #### 关于本文的讨论 ### 准备好了解更多了吗？