Netflix と Google の研究者
この問題は、バイナリ構造の使用、接続内のデータ フローを制限するシステム、フローの優先順位付けメカニズム、HTTP/2 接続で動作する ICMP のような制御メッセージの存在に関連して HTTP/2 プロトコルに導入された複雑さによって発生しました。レベル (ping、リセット、フロー設定など)。 多くの実装では、制御メッセージのフローが適切に制限されなかったり、リクエストの処理時に優先キューが効率的に管理されなかったり、フロー制御アルゴリズムの次善の実装が使用されたりしていました。
特定された攻撃方法のほとんどは、特定のリクエストをサーバーに送信することで、大量のレスポンスが生成されます。 クライアントがソケットからデータを読み取らず、接続を閉じない場合、サーバー側の応答バッファリング キューは常にいっぱいになります。 この動作により、ネットワーク接続を処理するためのキュー管理システムに負荷がかかり、実装機能によっては、使用可能なメモリまたは CPU リソースが枯渇してしまいます。
特定された脆弱性:
- CVE-2019-9511 (データ ドリブル) - 攻撃者は、スライディング ウィンドウのサイズとスレッドの優先順位を操作することで、大量のデータを複数のスレッドに要求し、サーバーにデータを 1 バイト ブロックでキューに強制します。
- CVE-2019-9512 (Ping フラッド) - 攻撃者が HTTP/2 接続経由で ping メッセージを継続的にポイズニングし、送信された応答の内部キューが反対側でフラッドする原因となります。
- CVE-2019-9513 (リソース ループ) - 攻撃者は複数のリクエスト スレッドを作成し、スレッドの優先順位を継続的に変更して、優先順位ツリーをシャッフルします。
- CVE-2019-9514 (リセット フラッド) - 攻撃者が複数のスレッドを作成する
各スレッドを通じて無効なリクエストを送信し、サーバーに RST_STREAM フレームを送信させますが、応答キューを満たすためにそれらのフレームを受け入れません。 - CVE-2019-9515 (設定フラッド) - 攻撃者は空の「SETTINGS」フレームのストリームを送信し、それに応答してサーバーは各リクエストの受信を確認する必要があります。
- CVE-2019-9516 (長さ 0 のヘッダー リーク) – 攻撃者が null 名と null 値を持つヘッダーのストリームを送信すると、サーバーは各ヘッダーを保存するためにメモリ内にバッファーを割り当て、セッションが終了するまでバッファーを解放しません。 ;
- CVE-2019-9517 (内部データ バッファリング) - 攻撃者が開く
サーバーが制限なくデータを送信できるようにする HTTP/2 スライディング ウィンドウ。ただし、TCP ウィンドウは閉じたままになり、データが実際にソケットに書き込まれるのを防ぎます。 次に、攻撃者は大量の応答を必要とするリクエストを送信します。 - CVE-2019-9518 (空のフレームのフラッド) - 攻撃者は、DATA、HEADERS、CONTINUATION、または PUSH_PROMISE タイプのフレームのストリームを送信しますが、空のペイロードとフロー終了フラグはありません。 サーバーは各フレームの処理に時間がかかり、攻撃者が消費する帯域幅とは不釣り合いです。
出所: オープンネット.ru