HTTP/2ボム：主要Webサーバーを脅かす高度なサービス拒否攻撃の手法

Califのセキュリティ研究者らは先ごろ、「HTTP/2ボム」と命名された深刻な脆弱性を発見しました。この攻撃手法を利用すると、リモートの攻撃者が主要Webサーバーのメモリを瞬時に枯渇させることができます。結果として、標的サーバーは完全なサービス拒否（DoS）状態に陥ります。

この脆弱性は、広く普及しているアーキテクチャのデフォルトHTTP/2設定に影響を与えます。対象となる主なソフトウェアには、nginx、Apache httpd、Microsoft IIS、Envoy、Cloudflare Pingoraが含まれます。注目すべき点は、この攻撃を実行するために大規模なボットネットが不要なことです。研究者の実証実験によれば、100 Mbpsの一般的な家庭用回線に接続した標準的なPCがあれば、脆弱なサーバーを数秒以内に無力化できるとされています。

二つの攻撃手法の融合

HTTP/2ボムは、二つの既存の攻撃手法を巧みに組み合わせたものです。具体的には、圧縮ボムの概念と、Slowlorisを彷彿とさせる接続維持戦術を融合させています。それぞれの手法は単独では、インフラ防御者やシステムアーキテクトにとって十分に知られた存在です。

しかし、この新たな攻撃フレームワークが際立った危険性を持つのは、二つの手法を組み合わせた相乗効果によるものです。まず攻撃者は、複雑なヘッダー処理のために大量のメモリブロックをサーバーに確保させます。その直後、クライアントは意図的に接続をオープンな状態に保ちます。この戦術により、バックエンドシステムは確保したコンピューティングリソースを解放できなくなります。

HPACKテーブルの仕組みを解剖する

圧縮コンポーネントが狙うのは、HTTP/2のネイティブなヘッダー圧縮アルゴリズムであるHPACKフレームワークです。ヘッダーは一般に、URIパス、暗号化されたCookie、キャッシュパラメータなど、通信に必要なメタデータを伝達します。圧縮なしでは、特に繰り返しリクエストが発生する場面でこれらのメタデータが膨大な帯域を消費します。HPACKはダイナミックインデックステーブルによってこのオーバーヘッドを効率的に削減しています。通常の通信では、ヘッダー文字列全体を一度だけ登録し、以降のリクエストでは1バイト程度の短いインデックス参照のみで済みます。

通常運用では、このアーキテクチャにより帯域消費を大幅に削減できます。しかしHTTP/2ボムは、この効率化の仕組みを強力な増幅装置へと変貌させます。攻撃者はまず特定のメタデータエントリをダイナミックインデックステーブルに事前登録しておきます。その後、短縮されたインデックス参照を数千回送信します。

逆説的なことに、ネットワークパケット内の1バイトがサーバーにメモリ上で完全なヘッダー構造を展開させます。これを単一リクエスト内で数千回繰り返すと、驚異的な非対称性が生まれます。攻撃者がほぼリソースを消費しない一方で、サーバーのメモリ容量は完全に枯渇してしまいます。

フロー制御の悪用

Slowloris的な要素は、HTTP/2プロトコルに組み込まれたフロー制御メカニズムを悪用します。本来このプロトコルは、データ受信側がウィンドウサイズを通知する機能を持っています。この通知により、送信側はどれだけのバイト数を送信できるかを把握できます。

HTTP/2ボムでは、クライアントがサーバーのレスポンスに対するフロー制御ウィンドウをゼロに設定します。その結果、Webサーバーは送信データを完結させることができなくなります。システムはアクティブなストリームを終了できず、ヘッダー処理のために確保したメモリを際限なく保持し続けます。

ストリームのアクティブ状態の維持

タイムアウトによる自動切断を防ぐため、攻撃者は定期的に小さなWINDOW_UPDATEフレームを送信します。サーバーはこの人工的なパルスを正常な通信活動と認識し、停止したストリームを維持し続けます。

しかし実際には、システムはリクエストのライフサイクルを終了させることができません。この同期ロックにより、フリーズしたストリームにメモリが長時間縛られたままになります。保持期間は、使用しているHTTP/2実装のタイムアウト設定にのみ依存します。

既存の脆弱性との構造的な違い

研究者たちは、この攻撃の各構成要素がまったく新しい概念ではないことを明確に強調しています。たとえばHPACKボムはCVE-2016-6581として2016年にはすでにセキュリティコミュニティで分析されています。同様に、Apache httpdでも同種のメモリ枯渇異常（CVE-2025-53020など）が以前に発見されています。さらに、CONTINUATIONフレームの不正形式やワーカースレッドの枯渇による類似のDoS脆弱性も過去に度々報告されてきました。それでもHTTP/2ボムが際立っているのは、独自の増幅ソースにあります。

従来の圧縮ボムは通常、インデックスマトリクスに巨大なペイロード値を埋め込んでから繰り返し参照するという手法を取ります。現代のWebサーバーは、展開後のヘッダーに対して厳格な容量制限を設けることでこの手法を容易に対策できます。そのため、単純なデータ膨張の試みはすぐにセキュリティ制限に引っかかります。

一方、この新しい攻撃手法はほぼ空のヘッダー文字列を使用します。深刻なリソース負荷は展開データの大きさからではなく、サーバーが各エントリの周囲に生成する複雑な構造メタデータラッパーから生じます。デコードするデータがほとんど存在しないため、従来の容量制限は作動しません。

Cookieフラグメント化によるバイパス

ヘッダーフィールド数を制限しているサーバーアーキテクチャに対して、研究者たちはHTTP CookieをたくみしたバイパスのBytes手法を発見しました。HTTP/2の公式仕様では、圧縮効率を最大化するために、単一のCookieヘッダーを複数の独立したフィールドに分割することが認められています。実証テストの結果、Apache httpdとEnvoyのいずれも、システム制限を検証する際にこれらの個別のCookieセグメントを標準ヘッダーフィールドとしてカウントしないことが判明しました。したがって、最終的なセキュリティへの影響は、アプリケーション層にリクエストを渡す前にサーバーが結合されたCookie文字列をどのように再構成するかに完全に依存します。

各サーバー実装における実証的な影響

以下の表は、テスト中にさまざまなサーバー環境で計測されたパフォーマンス低下と増幅率をまとめたものです。

実装別の動作分析

Envoyは各Cookieフラグメントを内部メモリバッファに直接追記します。攻撃者が大きなCookie値を数万回繰り返し参照すると、論理的な増幅比は約3,600:1に達します。さらに内部のソフトウェアオーバーヘッドにより、実際のメモリ消費はさらに大きくなります。CalifがEnvoy 1.37.2に対して行った実証テストでは、増幅係数は5,700:1という驚異的な値に達し、ターゲットシステムは10秒以内に約32 GBのメモリを消費しました。

Apache httpdは異なるアーキテクチャ上の動作を示しており、新しいフラグメントを受信するたびに統合されたCookie文字列を動的に再構築します。重要なのは、ストリームが完全に削除されるまで古いデータのコピーがメモリに保持される点です。この構造的な非効率性により、空のCookie文字列でも4,000:1の増幅比が生じます。CalifのPoC実証では、Apache httpd 2.4.67が約18秒で32 GB程度のシステムメモリを枯渇させました。

nginxとMicrosoft IISは相対的に低い増幅比を示しましたが、それでも完全なサービス拒否状態を引き起こすことに成功しています。実際の攻撃では、プロセスをクラッシュさせる必要はありません。より巧妙な戦略としては、プロセス終了の閾値をわずかに下回る水準でメモリ負荷を維持するという方法があります。これによりOSが深刻なスワップ状態に追い込まれ、正規ユーザーへのレスポンスタイムが著しく悪化します。

AIによる自律的な脆弱性発見

注目すべき点として、HTTP/2ボムはOpenAI Codexがサーバーのソースリポジトリを自律的に解析している際に最初に発見しました。Califのドキュメントによれば、このモデルが既存の二つの異なるレガシー概念を統合して高度に機能するエクスプロイトチェーンを生み出したとされています。この発見は、高度な脆弱性調査における機械知能の強力な能力を改めて浮き彫りにするものです。

さらに研究者たちは、パッチ公開から攻撃コードの実用化までの時間が劇的に短縮されていると警告しています。現代のAIツールはコードの差分から攻撃ロジックを直接かつ迅速にリバースエンジニアリングできるようになっています。

推奨される修正・緩和策

nginxの対応方針

Califは4月にnginxエンジニアへ脆弱性を最初に開示しました。これを受けて開発者は迅速にmax_headersディレクティブを導入し、翌日にはバージョン1.29.8をリリースしました。この設定パラメータはヘッダー数の上限をデフォルト値1,000に制限します。このアップデートをすぐに適用できない場合は、http2 off;ディレクティブでプロトコルを完全に無効化することを研究者たちは推奨しています。

Apacheのパッチ戦略

Apacheへの公式通知は5月27日に行われました。その結果として提供されたホットフィックスはmod_http2バージョン2.0.41に統合されています。このパッチにより、CookieフラグメントはLimitRequestFieldsの境界値に対して厳密に検証されるようになりました。このパッチはスタンドアロンのmod_http2ブランチとマスターリポジトリには反映されていますが、安定版のApache httpd 2.4.xリリースラインにはまだ取り込まれていません。アップデートが不可能な場合は、Protocols http/1.1でプロトコルを無効化する一時的な緩和策を実施できます。

ApacheのLimitRequestFieldSizeを小さくすることで、再構築されるCookieの総サイズを制限し、ローカルスレッドへのダメージを部分的に緩和できます。ただし、この調整だけではセキュリティ上の脆弱性を包括的に無効化することはできません。攻撃者は複数の独立したストリームや同時接続に計算負荷を分散させることが容易です。さらにLimitRequestFieldsを減らしても、サーバーがCookieの繰り返しフラグメントを独立した個別エントリとして扱わない限り、保護効果はまったくありません。

IIS・Envoy・Pingoraへのゼロデイ対策

Califの公開時点では、Microsoft IIS、Envoy、Cloudflare Pingoraに対する公式パッチは提供されていませんでした。これらの環境では、運用上許容できる場合はHTTP/2を無効化することを研究者たちは推奨しています。代替策として、上流のリバースプロキシを展開して受信ヘッダー数を厳密に制御する方法もあります。この防御層は、分割されたCookieフラグメントも含めたフィールド数とともに、展開後のヘッダーの総サイズも包括的に評価する必要があります。

結論：アーキテクチャ上の本質的な教訓

HTTP/2終端エンドポイントにおける普遍的なセキュリティ原則は明快です。容量制限とフィールド数制限は、それぞれ異なるリスクに対応するものです。したがって、安全なアーキテクチャには両方の防御が同時に必要です。また、クライアントが接続を維持するために定期的にWINDOW_UPDATEフレームを送信している場合であっても、停止したストリームには厳格な有効期限を設けなければなりません。

ソフトウェアのアップデートやプロトコルの無効化が不可能な場合、Califはcgroups、ulimit -v、またはコンテナ定義を通じてワーカープロセスのメモリ割り当てを制限することを提案しています。この戦略は根本的な脆弱性を解消するものではありませんが、障害の形態を根本的に変えることができます。メモリを使い果たしたワーカープロセスを迅速に終了・再起動できる環境を整えることが非常に重要です。この対策により、攻撃者がシステム全体のメモリを掌握して隣接する正規リクエストを妨害することを防ぐことができます。

最終的に、根本的なアーキテクチャ上の見落としは特定のソフトウェア実装にあるのではありません。むしろ、公式仕様がメモリ枯渇リスクをどのように規定しているかという点に問題があります。HPACK標準はダイナミックテーブルによる増幅の脅威を想定しており、SETTINGS_HEADER_TABLE_SIZEによるリスク軽減を提案しています。しかしHTTP/2ボムは別の攻撃経路を露わにしました。クライアントが無償で接続を無期限に維持し、確保したメモリを未完のストリームに永続的に縛り付けられる状況では、わずかな増幅比でさえ致命的な威力を持ちます。