HTTP/2 継続フラッド: 技術的詳細

 (nowotarski.info)
3 ポイント 投稿者 GN⁺ 2024-04-06 | 1件のコメント | WhatsAppで共有

HTTP/2 CONTINUATION Flood 脆弱性: 技術的詳細

  • CONTINUATION Flood は、複数の HTTP/2 プロトコル実装で見つかった脆弱性のカテゴリであり、Rapid Reset 攻撃よりも深刻な脅威をもたらす。
  • 攻撃による結果はサーバークラッシュから性能低下までさまざまであり、攻撃リクエストは HTTP アクセスログに現れない。

序文

  • 2023年10月に HTTP/2 Rapid Reset 攻撃を知り、HTTP/2 に対するセキュリティ分析の観点から研究を始めることにした。

HTTP/2 の簡単な紹介

  • HTTP/1.1 と HTTP/2 の主な違いは、後者がバイナリプロトコルであり、クライアントとサーバーがテキスト行の代わりに フレーム を交換することにある。
  • HEADERS フレームと CONTINUATION フレームの説明が必要である。

HEADERS フレーム

  • HEADERS フレームは、リクエストとレスポンスの HTTP ヘッダーを送信するために使われ、HPACK エンコーディングアルゴリズムを使用してヘッダーデータを圧縮する。
  • フレームには END_HEADERS や END_STREAM のようなフラグを設定できる。

CONTINUATION フレーム

  • CONTINUATION フレームは HEADERS フレームと非常によく似ているが、END_HEADERS フラグだけを持ち、このフラグが設定されるとヘッダーストリームが終了したことを意味する。

CONTINUATION Flood 脆弱性

  • クライアントが新しい HTTP/2 ストリームを開始し、HEADERS と CONTINUATION フレームを送るものの、END_HEADERS フラグが 決して 設定されない場合、サーバーは無限のヘッダーストリームを解析してメモリに保存し続けなければならない。
  • HTTP/1.1 では、ヘッダーサイズ制限とリクエスト/ヘッダータイムアウトによって無限ヘッダーから保護されるが、多くの HTTP/2 サーバーではこれらの保護措置が欠けているか、誤って実装されていた。

CPU 消費: Golang の事例

  • Golang は CONTINUATION Flood による CPU 消費の例であり、http2MetaHeadersFrame という抽象クラスを使って HEADERS フレームと CONTINUATION フレームを処理している。
  • HPACK デコーダーはヘッダーサイズ制限に達するとヘッダーの出力を停止するよう設定されているが、END_HEADERS フラグがなければ関数は戻らず、ヘッダーのデコードを続けてしまう。

メモリ枯渇

  • メモリ枯渇は最も深刻なケースのひとつであり、CONTINUATION フレームを使って構築されるヘッダー一覧のサイズを制限しない実装がある。
  • ヘッダータイムアウトのない実装では、単一の HTTP/2 接続だけでサーバーをクラッシュさせることができる。

到達可能なアサーション衝突: Node.js（特殊なケース）

  • Node.js は CONTINUATION フレームの無限ストリームを適切に処理するが、ヘッダーストリームの途中で接続が切断されるとデータ競合バグが発生する。
  • Node.js は Http2Session デストラクタ内でメモリアロケーションを追跡しており、接続が切断される際に current_nghttp2_memory_ の値が同時に更新されて衝突が発生する可能性がある。

以前の HTTP/2 脆弱性との比較

  • 過去には複数の HTTP/2 脆弱性が報告されており、CONTINUATION Flood はそれらの過去の脆弱性とは異なる形で動作する。
  • CONTINUATION Flood は空のヘッダーを送る代わりに、サーバーによって設定されたフレームサイズ制限いっぱいまで、多数の任意ヘッダーを送信する。

最終所見

  • HTTP/2 トラフィックは人間による HTTP トラフィック全体の約60%を占めており、影響を受けるプロジェクトの重要性を考えると、インターネットのかなりの部分が容易に悪用可能な脆弱性の影響を受けていた。
  • この脆弱性が実地で悪用されていたなら、サーバー管理者にとって適切な HTTP/2 の知識なしにデバッグするのは非常に困難だっただろう。

GN⁺ の意見

  • この脆弱性はサーバーの可用性を深刻に損なう可能性があり、とくにログに記録されないため追跡と対応が難しい。
  • サーバー管理者は定期的にセキュリティアップデートを適用し、トラフィック分析ツールを使って異常なパターンを検出する必要がある。
  • このような脆弱性はサイバーセキュリティコミュニティに警鐘を鳴らし、より安全なプロトコル設計と実装の重要性を強調している。
  • 批判的に見れば、この脆弱性は広く使われているプロトコルの基本設計上の欠陥を露呈しており、これはインターネットの基盤インフラに対する信頼性の問題を提起する。
  • 関連分野の知識を持つ専門家でなければ、このような複雑な脆弱性を理解して対処するのは難しい可能性があるため、セキュリティ教育と認識向上が必要である。

関連記事

1件のコメント

 
GN⁺ 2024-04-06
Hacker Newsのコメント

  • この問題は最近 Bandit で解決された

    • 1か月前に Bandit で同じ問題を解決したという個人的な経験。
    • リンクを通じて具体的なコード位置を提示。
    • 実装者の視点ではこの問題は非常に明白で、他の実装でもすでに防御策が用意されているものと思っていた。
    • しかし数十の実装を確認した結果、主要な HTTP/2 サーバーでさえこの種の保護機構がないか、誤って実装されていた。

  • 開発文化への批判

    • 開発者が自動的に動的拡張されるものに慣れすぎていて、何がどこまで大きくなり得るのかを考えない文化が問題だと指摘。
    • こうした問題は HTTP/2 に限ったものではないが、HTTP/2 の複雑さが問題をさらに悪化させうる。
    • 過去の HTTP/1.x 時代には C のような言語を使い、バッファ長の管理に継続的な注意が必要で、リクエストヘッダーの割り当てを無制限に拡張するようなことはなかった。

  • 影響を受けないサーバー/リバースプロキシの一覧

    • 以前の記事で言及された、影響を受けない Web サーバーおよびリバースプロキシの一覧。
    • Nginx、Jetty、HAProxy、NetScaler、Varnish は影響を受けない。

  • HTTP/1.1 の安全性についての考察

    • 自分たちのサイトが一日中注目を集めていたと言及。
    • 自分たちのサイトのトラフィックが少ない場合、HTTP/1.1 を使うほうがより安全なのかという疑問を提起。

  • 著者への称賛

    • 著者が広い視野で取り組み、発見内容を責任を持って報告し、読みやすい形で共有したことへの称賛。

  • Slowloris v2 への言及

    • この問題をゆっくり発生させれば "slowloris v2" と呼べるだろうという冗談。

  • 誤字への言及

    • "serveral retries" という誤字を面白がっている。

  • HTTP/2 に対する批判的な見方

    • HTTP/2 をどのようにアプリケーション層プロトコルの「アップグレード」のためのトランスポート層として押し込めるのか、という批判。