要約

  • HTTP/2 Rapid Resetは、ストリームを作成した直後にキャンセルする動作を大量に繰り返し、サーバー側に不釣り合いな処理を発生させることで、資源枯渇を引き起こし得る。これは単一製品の欠陥ではなく、HTTP/2実装全体に関係する問題として記録された。
  • RFC、作業部会の議論、ベンダーのリリース、パッケージのバックポート、運用者の設定と監視は、それぞれ異なる修復証拠である。いずれか一つだけでは、インターネット全体の展開完了を証明できない。

問題は「RST_STREAMがあること」ではなく、仕事と取消しの非対称性だった

HTTP/2は、1本の接続上で複数のストリームを多重化する。RFC 9113は、ストリームの状態とフレームの振る舞いを定め、RST_STREAMによってストリームを終了できることを規定している。RFCは2022年6月に公開され、CVE-2023-44487の公表より前の文書である。HTTP/2の仕様

Rapid Resetで問題になったのは、キャンセル信号が存在するという単純な事実ではない。攻撃者がストリームを繰り返し開始し、直後にリセットすることで、同時に維持されるストリーム数を低く抑えながら、サーバーには解析、スケジューリング、状態管理、リクエスト処理の仕事を発生させられる点である。Google、Cloudflare、Akamaiはいずれも、作成と取消しの反復がサーバー側の処理を増幅する仕組みとしてこの攻撃を説明している。Google Securityの解説ただし、各社の攻撃規模、観測期間、検知方法は自社ネットワークに依存する。Google Cloudの分析Cloudflareの技術分析Akamaiの解説

したがって、影響の中心は「何本のストリームが現在開いているか」という静的な数値だけでは捉えにくい。一定時間内にどれだけ作成され、どれだけキャンセルされ、キャンセル済みの仕事がどこまで進んだかを見なければならない。防御側が接続数や同時ストリーム数だけを監視していれば、攻撃者が低い同時実行数のまま高い作業量を作る可能性を見落とす。

脆弱性の記録は、故障の所在を単一製品から切り離した

CVE-2023-44487は、HTTP/2実装における高速なストリームリセットの反復を原因とするサービス拒否状態として登録されている。NVDとCVE Programは共通識別子と影響情報を提供するが、特定製品の修正版、影響を受ける版、バックポートの有無を確定するには、各ベンダーとディストリビューションの資料を確認する必要がある。NVDの記録CVEレコード

CERT/CCは2023年10月10日付で、複数のHTTP/2実装に関係する攻撃を説明し、ベンダー更新と、実装ごとに利用できる同時ストリーム数、リクエスト率、リセット挙動などの制御を推奨した。ここで重要なのは、設定上の制限とベンダーの修正が同じものではないという区別である。制限は攻撃の成立条件や影響を減らすことがあるが、プロトコル処理や実装内部の問題を修正したことの証明にはならない。CERT/CCの勧告

この区別は責任の境界を明確にする。標準化団体はプロトコルの意味と相互運用性を扱う。実装者は、仕様に従うコードが過大な仕事をしないように修正する。ディストリビューションは、上流の版変更だけでなく、既存のサポート版に修正をバックポートする場合がある。製品の利用者は、自分の環境で実際に修正版が動作しているか、また防御設定が適用されているかを確認する。

「修正済みの版」は、利用者の修復を意味しない

Envoyのバージョン履歴は、Rapid Resetに関係する修正や設定変更を実装のリリース系列に結びつけている。NGINXの資料は製品ごとの影響と緩和策を説明し、Red HatはCVEを製品、リリース、パッケージの状態に分けて追跡している。これらの資料が示すのは、修復確認の単位が「HTTP/2を使っているか」では粗すぎるということである。Envoyの履歴NGINXの説明Red Hatの勧告

同じソフトウェア名でも、利用しているブランチ、OSディストリビューション、アーキテクチャ、更新チャンネル、製品への組込み方によって状態が異なる。上流の版番号が変わっていなくても、ディストリビューションが修正をバックポートしている場合がある。逆に、ベンダーが修正版を公開していても、運用者が更新を適用していない、負荷分散装置の一部だけが古い、あるいは別の場所で同じライブラリを組み込んだサービスが残っている可能性がある。

そのため、修復の主張は少なくとも四つの証拠に分けるべきである。第一は、問題の動作と影響を示す脆弱性記録。第二は、どの実装のどの版が修正されたかを示すベンダー資料。第三は、運用環境のパッケージと設定がその修正に対応していること。第四は、異常な作成・リセット比率や資源消費が残っていないことを示す監視、試験、または外部測定である。

IETFのレビューは、修正案と展開証拠を分けて扱う

HTTPbisのドラフトとHTTP Working GroupのIssue 846は、公開後にRapid Resetを検討し、プロトコル文書に対する応答を議論した経路を示す。作業部会の議論は、観測された問題を標準の文言で扱うべきか、実装ガイダンスで扱うべきか、複数の案のどれが相互運用性を損なわずにリスクを減らせるかを考える場になる。HTTP/2bisドラフトIssue 846

しかし、ドラフトは最終RFCではない。Issueのコメントも、採用された規範的要求と同じではない。標準の改訂が成立したとしても、既存の実装が自動的に変わるわけではない。ここに、標準化の成功と運用上の修復完了との間にある、制度的な空白が現れる。

IETFは、実装者や運用者に代わって全インターネットの更新を実行する組織ではない。IETFの文書が、問題を説明し、相互運用可能な解決策を提示し、更新すべき処理を明確にできることは重要である。一方で、修正版を各製品に組み込み、各配布物に届け、各組織が保守対象を把握し、更新後の挙動を検証する責任は別の場所にある。IETF-W3Cを一つの指揮系統として理解すると、この分散した責任構造を誤って単純化する。

検知から対応までの経路は、単線ではなかった

公開資料から再構成できる経路は、単なる「脆弱性発見からパッチ公開まで」の直線ではない。まず、HTTP/2の挙動が攻撃者に利用され、Google、Cloudflareなどの事業者が大規模な攻撃活動を観測した。次に、脆弱性識別子とCERT/CCの協調開示が、複数の実装者に共通する問題として可視化した。各ベンダーはそれぞれの製品、ブランチ、設定体系に応じた対応を出した。同時に、HTTP Working Groupでは、仕様上の説明や将来の文書の扱いが議論された。

この経路の各段階は異なる問いに答える。観測は「攻撃または異常な挙動が現実に起きたか」を問う。CVEと協調開示は「同一の問題として誰が影響を受け得るか」を整理する。ベンダー資料は「特定の製品で何を変更したか」を示す。標準化作業は「相互運用可能なプロトコルの説明と将来の実装がどうあるべきか」を扱う。運用監視は「自分の環境でリスクが残っているか」を問う。

CISAのKnown Exploited Vulnerabilitiesカタログは、掲載が確認できる場合、実際の悪用に基づく優先対応の根拠になる。ただし、カタログへの掲載はインターネット上の脆弱なシステムの割合を測るものではなく、全組織の露出や修正完了を証明するものでもない。カタログの状態や期限は、参照した時点のスナップショットとして扱う必要がある。CISA KEVカタログ

修復完了を何で証明するか

Rapid Resetの事例から得られる実務上の基準は、パッチの公開日ではなく、検証可能な閉鎖条件を定義することである。まず、資産台帳にHTTP/2の終端箇所を記録し、直接のサーバーだけでなく、プロキシ、ロードバランサー、サービスメッシュ、アプリケーションに組み込まれたライブラリを含める。次に、各箇所について実装名、正確な版またはパッケージリリース、バックポートの状態、更新チャンネルを確認する。

そのうえで、運用者は設定を修正の代替ではなく、追加の制御として扱うべきである。ストリーム数、リクエスト率、リセット比率、接続ごとの資源消費、上流への伝播を監視し、通常時の基準値と異常時の対応を定める。攻撃の特徴が検出されたとき、遮断、レート制限、HTTP/2の一時的な無効化、上流への切替など、サービスの重要度に応じた選択肢を持つ必要がある。

最後に、更新後の確認には「版が新しい」という証拠だけでなく、「修正された挙動が実際に動いている」という証拠を加える。テスト環境での再現試験、リセット処理時の資源消費の観測、外部からの構成確認、インシデント後のログレビューなどが候補になる。ただし、公開資料は世界全体の修復率を示していない。今回確認できる資料から、修正後に全HTTP/2サービスの何パーセントが安全になったかを導くことはできない。

残る問いは、標準ではなく証拠の連結にある

HTTP/2 Rapid Resetは、標準化機関が問題を見つけられなかったという単純な物語ではない。RFC 9113に定められた動作、攻撃者による利用、事業者の検知、協調開示、実装修正、作業部会でのレビュー、運用者の更新が、別々の責任主体によって接続された事例である。問題は、どの主体が何を制御し、どの証拠を次の主体へ渡すかにある。

この観点では、修復の成果を三つに分けるとよい。第一は、失敗の説明が共有されたこと。第二は、実装と設定に対応する対策が利用可能になったこと。第三は、対象環境で露出が閉じ、再発を検出できることだ。第一と第二は、RFC、脆弱性記録、ベンダーリリース、標準化議論で裏付けられる。第三は、各運用者の資産、更新、テレメトリー、継続的な検証なしには確認できない。

従って、Rapid Reset後の説明で「パッチが出たので解決した」と書くのは不十分である。より正確な表現は、「複数の実装に対する修正と緩和策が公開され、標準化上の検討も進んだ。しかし、特定の運用環境で修復が完了したこと、まして全体の露出が閉じたことは、別の証拠を必要とする」である。この限定は弱さではない。分散したインターネット基盤において、責任の所在と証拠の範囲を取り違えないための最低条件である。