Logo
x logo
2025-08-16

HTTP/2 MadeYouReset 脆弱性により大規模なDDoS攻撃が可能に

要約

セキュリティ研究者が、HTTP/2プロトコルの重大な脆弱性「MadeYouReset」を公開しました。この脆弱性を悪用すると、世界中の数百万のWebサーバーに対して大規模なDDoS攻撃を仕掛けることができます。

このニュースのスケール度合い
9.5
/10
インパクト
9.8
/10
予想外またはユニーク度
9.0
/10
脅威に備える準備が必要な期間が時間的にどれだけ近いか
9.5
/10
このニュースを見て行動が起きるあるいは行動すべき度合い
9.0
/10

詳細分析

主なポイント

  • HTTP/2プロトコルの「MadeYouReset」脆弱性の発見
  • この脆弱性を悪用すると、サーバーの同時接続数制限を無効化し、大規模なDDoS攻撃を可能にする
  • 2023年の「Rapid Reset」攻撃を上回る影響が懸念される

社会的影響

  • 世界中のWebサーバーが攻撃対象となる可能性がある
  • DDoS攻撃による企業や組織のサービス停止や経済的損失が懸念される
  • インターネットインフラの機能停止により、社会的混乱が引き起こされる可能性がある

編集長の意見

この脆弱性は、HTTP/2プロトコルの根本的な設計上の問題に起因しており、根本的な解決には時間がかかると考えられます。DDoS攻撃に強いアーキテクチャの構築が必要不可欠でしょう。
本日はこの「MadeYouReset」について深掘りします。

解説

HTTP/2プロトコルにおける「MadeYouReset」という名の脆弱性について

はじめに

2025年8月13日に公に開示されたHTTP/2プロトコルにおける「MadeYouReset」と名付けられた深刻な脆弱性(CVE-2025-8671)は、世界中の何百万ものウェブサーバーに影響を与える可能性のある大規模な分散型サービス拒否(DDoS)攻撃を可能にします。この脆弱性は、2023年に甚大な被害をもたらした「Rapid Reset」攻撃の基盤の上に構築されていますが、従来の緩和策を回避する巧妙な「ひねり」が加えられています。

MadeYouResetは、HTTP/2の組み込みの同時接続数制限(MAX_CONCURRENT_STREAMS)を回避することを可能にし、攻撃者が最小限のリソースでターゲットサーバーに事実上無制限の同時処理を発生させることができるようにします。これは、従来のDDoS攻撃手法と比較して非常に非対称な性質を持ち、攻撃側ははるかに少ない帯域幅と計算能力でサーバーを圧倒できます。その結果、ほとんどのHTTP/2準拠の実装が影響を受け、多くのサーバーが完全にサービス拒否に陥るか、メモリ不足によるクラッシュ(OOM)を引き起こすことがテストで明らかになっています。この新たな脅威は、既存のDDoS防御戦略に大きな課題を突きつけており、緊急の対策が求められています。この研究は、セキュリティ専門家のGal Bar-Nahum氏がテルアビブ大学のAnat Bremler-Barr教授およびYaniv Harel氏と共同で実施しました。

MadeYouReset攻撃の手法

MadeYouReset攻撃の手法を理解するためには、まずHTTP/2の基本的な仕組みと、その前身である「Rapid Reset」脆弱性を知る必要があります。

  1. HTTP/2の基本的な仕組み
    HTTP/2プロトコルは、クライアントとサーバー間の通信を効率化するために、複数のリクエストとレスポンスを同時に処理できる「ストリーム」という概念を導入しています。各HTTPリクエストとレスポンスは、それぞれ独立したストリーム上で送受信されます。
  • フレーム: HTTP/2の最小通信単位であり、HTTPヘッダー、ペイロード、プロトコル制御情報など、特定の種類のデータを運びます。
  • ストリーム: HTTPリクエストとレスポンスが送受信される仮想チャネルです。各ストリームは1つのリクエスト-レスポンスサイクルを運びます。
  • MAX_CONCURRENT_STREAMS: HTTP/2プロトコルには、悪意のあるクライアントが多数の同時リクエストを開いてサーバーを過負荷にすることを防ぐための、クライアントが同時に維持できるアクティブなストリームの数に上限を設けるパラメータがあります。このデフォルト値は、ほとんどのHTTP/2サーバーと実装で100に設定されています。理論的には、これはサーバー過負荷を防ぐための優れたメカニズムでした。
  1. Rapid Reset脆弱性(MadeYouResetの前身)
    2023年10月に公にされた「Rapid Reset」は、HTTP/2プロトコルのゼロデイ脆弱性であり、当時史上最大のDDoS攻撃に悪用されました。
  • リクエストキャンセル機能の悪用: HTTP/2では、クライアントが送信したリクエストの応答に関心がなくなった場合、RST_STREAMフレームを使用してそのストリームをキャンセルする機能が導入されました。RFCのストリーム状態マシンによると、RST_STREAMフレームによってストリームがキャンセルされると、そのストリームはすぐに「クローズされた」と見なされ、MAX_CONCURRENT_STREAMSの制限にはカウントされません。
  • サーバーのバックエンド処理の継続: 理論上、ストリームがキャンセルされると、サーバーはそのHTTPリクエストの処理を中止し、応答の送信を中止すべきです。しかし、実際には、多くのサーバーと実装において、リクエストのキャンセルは応答の送信を中止するだけで、サーバーのバックエンドはHTTPリクエストの処理と応答の計算を継続していました。サーバーのHTTP/2コンポーネントがキャンセルされたリクエストの応答を受け取ると、ストリームが既にクローズされているため、その応答は破棄されます。
  • Rapid Reset攻撃の手法: Rapid Reset攻撃は、ストリームを開いた後、RST_STREAMフレームを使用して即座にキャンセルするというシンプルな手法を使用します。これにより、HTTPリクエストはバックエンドで処理され、応答が計算されるにもかかわらず、MAX_CONCURRENT_STREAMSにはカウントされません。結果として、攻撃者はストリームのキャンセルを利用して、HTTP/2プロトコルによって課せられる同時接続数の制限を完全に回避しながら、無制限の同時リクエストをサーバーに処理させ、応答を計算させることが可能になりました。これは、従来のHTTP/2リクエストフラッド攻撃に比べてはるかに優れており、攻撃者自身のスループットのみによって制限されました。
  1. Rapid Resetの緩和策
    Rapid Resetに対する一般的な緩和策は非常に単純でした。それは、クライアントが送信できるRST_STREAMフレームの数を制限するというものでした。例えば、100という制限は、正当なユーザーには影響を与えずに攻撃を完全に軽減するのに十分でした。クライアントからのRST_STREAMがなければ、Rapid Reset攻撃は実行できませんでした。そして、この対策は非常に効果的でした。

  2. MadeYouReset攻撃の手法
    ここからが「MadeYouReset」の巧妙な「ひねり」です。Rapid Resetの緩和策はクライアントがRST_STREAMを送信するのを阻止しましたが、MadeYouResetはクライアントがリクエストをキャンセルする代わりに、サーバーに強制的にリクエストをキャンセルさせることで、この緩和策を完全に回避します。

  • 目標の再定義: 攻撃の目標は「キャンセル」そのものではなく、「RST_STREAMフレームが生成されるあらゆる経路」です。幸いなことに、HTTP/2においてRST_STREAMは、クライアントからのキャンセルだけでなく、ストリームエラーを通知するためにも使用されます。
  • 重要ポイント:バックエンド処理の継続: MadeYouResetが機能するためには、ストリームがサーバーが処理を開始する有効なリクエストから始まり、その後、サーバーがRST_STREAMを発行するようなストリームエラーを引き起こす必要があります。同時に、バックエンドは応答の計算を継続していなければなりません。単に不正なリクエストを送信するだけでは、サーバーがバックエンド処理を開始しないため、この目的には適しません。
  • 攻撃手法:制御フレームの悪用: HTTP/1.1とは異なり、HTTP/2にはHTTPメッセージに加えて、接続フローを形成する「制御フレーム」が存在します。研究者たちは、特定の無効な制御フレームを作成したり、プロトコルのシーケンスを適切なタイミングで違反させたりすることで、サーバーが既に有効なリクエストを運んでいるストリームに対してRST_STREAMを送信させることができる方法を6つ発見しました。これらの「サーバーにRST_STREAMを送信させる」プリミティブはRFCで定義されているため、RFC準拠のあらゆる実装に適用されます。
  • 緩和策の回避: MadeYouResetは、これらの手法(6つのプリミティブのいずれか)を使用することで、攻撃者がRST_STREAMを一切送信する必要がありません。これにより、一般的なRapid Resetの緩和策(クライアントが開始したキャンセルをカウントする)を完全に回避しながら、Rapid Resetと同じ影響を達成します。サーバーは「自己キャンセル」されたリクエストのバックエンド処理を継続するため、無制限の作業がサーバーに課せられることになります。
  • 非対称な影響: 攻撃の有効性は、サーバーの能力(CPU、メモリ、I/O、ワーカープール)、攻撃者の送信レート(帯域幅とクライアントCPU)、ターゲットリソースの複雑さ(計算にかかる時間)に依存します。しかし、リクエストの送信にかかるコストが低く、応答の計算にかかるコストが高いという非対称性と、攻撃者が簡単に無制限のアクティブなリクエストを作成できるという事実により、ほとんどのサーバーは完全なDoS攻撃に脆弱であり、かなりの数がメモリ不足(OOM)によるクラッシュも引き起こします。たとえ一部のリクエストが重いバックエンド処理に到達しなくても、ストリームオブジェクトの作成と破棄、フレームの解析、ステートマシンの進行、HPACKの維持、クリーンアップといった高頻度な処理自体が、HTTP/2フロントエンドでかなりのCPUとメモリを消費します。大規模になると、そのオーバーヘッドだけでも深刻なパフォーマンス低下やDoSを引き起こす可能性があります。

おわりに

「MadeYouReset」脆弱性は、HTTP/2プロトコルにおける極めて深刻な欠陥であり、その影響は広範囲にわたります。この攻撃は、2023年の「Rapid Reset」攻撃の防御策として多くのサーバーが導入した「クライアントが送信するRST_STREAMフレームの数を制限する」という対策を、サーバー自身にRST_STREAMフレームを生成させるという巧妙な手法で完全に回避します。これにより、攻撃者はごくわずかなリソースで、ターゲットサーバーに無制限の同時処理を課し、サービス拒否状態に追い込むことが可能になります。

この脆弱性は、Netty、Apache Tomcat、F5 BIG-IP、H2Oなど、ほぼ全てのHTTP/2準拠の実装に影響を与えることが確認されており、多くのサーバーが完全にサービス停止するか、メモリ不足によるクラッシュに至る可能性があります。この攻撃の非対称性、すなわち攻撃者側のコストが低い一方で、サーバー側の処理コストが高いという特性が、ほとんどの実装を脆弱にしています。

このような状況を踏まえ、HTTP/2サーバーを運用する組織は、直ちにベンダーのアドバイザリを確認し、利用可能なパッチを適用してこの重要な脆弱性を軽減することが不可欠です。今回のMadeYouResetの発見は、DDoS攻撃の手法が常に進化しており、それに対応するセキュリティ対策も絶え間なく改善されなければならないという事実を改めて示しています。継続的なセキュリティ研究と迅速な対策の実施が、増大するサイバー脅威からシステムを保護する上で極めて重要です。


より詳細に知りたい方のために。ステップバイステップでまとめてみました。

MadeYouResetの脆弱性について、段階を追って詳しく説明します。この脆弱性は、HTTP/2プロトコルに存在する重大な欠陥であり、大規模な分散型サービス拒否(DDoS)攻撃を可能にするものです。2023年に発生した「Rapid Reset」攻撃の仕組みを基盤としつつ、一般的な対策を回避する巧妙な「ひねり」が加えられています。


MadeYouResetを詳しく知りたい方のために

Step1. HTTP/2の基本と脆弱性の背景を理解する

まず、MadeYouResetがどのように機能するかを理解するために、HTTP/2のいくつかの基本的な概念を押さえる必要があります。

  • ストリームとフレーム
    HTTP/2は、情報を「フレーム」という最小単位でやり取りし、これらのフレームは「ストリーム」という仮想チャネルを通じて送受信されます。各ストリームは、1つのリクエストとそれに対応するレスポンスのサイクルを処理します。
  • 同時実行ストリームの制限(MAX_CONCURRENT_STREAMS)
    HTTP/2は、クライアントが同時に開くことができるアクティブなストリームの数を制限するためにMAX_CONCURRENT_STREAMSというパラメータを持っています。これにより、悪意のあるクライアントがサーバーに過負荷をかけるのを防ぐことが意図されています。サーバーが圧倒された場合、この値を減らしてクライアントに通知することも可能です。デフォルト値はほとんどのHTTP/2サーバーで100です。
  • RST_STREAMフレーム
    これは、HTTP/2における特別な制御フレームの一つで、ストリームのキャンセルやストリームエラーの通知に使われます。クライアントがこのフレームを送信すると、サーバーに対してそのリクエストへの関心を失ったことを伝え、サーバーは通常、そのストリームでの作業を停止します。
  • バックエンド処理の継続
    しかし、HTTP/2サーバーの多くでは、RST_STREAMフレームを受け取ってストリームがキャンセルされた(またはエラーでリセットされた)後でも、サーバーのバックエンドはリクエストの処理とレスポンスの計算を続けてしまうという問題があります。サーバーのHTTP/2コンポーネントはストリームがクローズされたことを認識し、計算されたレスポンスを破棄しますが、バックエンドでの計算は既に始まってしまっているため、リソースが無駄に消費され続けます。この非対称性が、DDoS攻撃の根本的な原因となります。

Step2. Rapid Resetの概要(MadeYouResetの先駆け。2023年に発覚した脆弱性)

MadeYouResetを理解する上で、「Rapid Reset」攻撃の知識は不可欠です。なぜなら、MadeYouResetはRapid Resetの対策を回避するために設計されたものだからです。

  • Rapid Resetの仕組み:
    Rapid Reset攻撃は、HTTP/2が導入した「リクエストキャンセル機能」を悪用します。攻撃者は、ストリームを高速で開き、すぐにRST_STREAMフレームを使ってそれをキャンセルします。
  • 同時実行制限のバイパス:
    RFCのストリーム状態マシンによれば、RST_STREAMフレームによってキャンセルされたストリームは、直ちに「クローズ済み」とみなされます。クローズされたストリームは、MAX_CONCURRENT_STREAMSの制限にカウントされません。これにより、攻撃者はサーバーが「アクティブ」とみなすストリーム数を制限内で保ちながら、バックエンドで処理される実際の作業量を無限に増やせるようになりました。
  • 甚大な影響:
    この手法により、Rapid Resetは2023年に発生した最大のDDoS攻撃の一つとなり、ほぼすべてのHTTP/2サーバーに影響を与えました。攻撃者は、自身のスループットのみに制限される形で、サーバーに過剰な処理を押し付けることができました。
  • Rapid Resetの対策:
    Rapid Resetに対する一般的な対策は、クライアントが送信できるRST_STREAMフレームの数を制限することでした。これにより、クライアントによるリクエストキャンセルができなくなり、Rapid Reset攻撃は効果的に緩和されました。

Step3. MadeYouResetの「ひねり」と動作原理

さて、いよいよここからがMadeYouResetの核心です。
MadeYouResetは、Rapid Resetの対策(クライアントからのRST_STREAMの数を制限すること)を迂回するために、より巧妙な方法を考案しました。

  • 「サーバーにリセットさせる」というひねり:
    MadeYouResetの「ひねり」は、クライアントが自らリクエストをキャンセルするのではなく、サーバーにリクエストをキャンセルさせるという点にあります。

  • なぜそれが可能か:
    RST_STREAMフレームは、クライアントによるキャンセルだけでなく、ストリームエラーのシグナルとしても使用されます。MadeYouResetは、この「ストリームエラー」を悪用します。

  • 攻撃が成功するための条件:
    MadeYouResetが機能するためには、ストリームが有効なリクエストから始まり、サーバーがその処理を開始した後で、ストリームエラーをトリガーしてサーバーにRST_STREAMを発行させる必要があります。単に不正なリクエストを送っても、サーバーはすぐにそれを拒否し、バックエンド処理は開始されないため、攻撃にはなりません。

  • 6つの「MadeYouResetプリミティブ」:
    研究者たちは、サーバーにRST_STREAMを発行させる6つの異なる手法を特定しました。これらは、RFCに定義されたストリームエラーに該当するため、HTTP/2に準拠するほとんどすべての実装に影響を与えます。これらのプリミティブは、以下の2つのカテゴリに分類されます。

    1. 不正な制御フレーム:フレーム自体がRFCの構造に違反している場合です。

      • WINDOW_UPDATEフレームをインクリメント値0で送信する:WINDOW_UPDATEフレームは、ピアが送信できるデータ量を増やすためのものです。インクリメント値が0の場合、何も起こらないため、プロトコルはこれをストリームエラーとみなし、サーバーにRST_STREAMを送信させます。
      • PRIORITYフレームを長さ5以外で送信する:PRIORITYフレームの有効な長さは5のみです。これ以外の場合、サーバーはストリームエラーとして処理します。
      • PRIORITYフレームでストリーム自身に依存関係を持たせる:HTTP/2の優先度付けスキームでは、ストリームが自分自身に依存することはできません。このケースもストリームエラーとみなされ、RST_STREAMをトリガーします。
    2. 不適切なプロトコルフロー:フレーム自体は構文的に有効ですが、ストリームの現在の状態では有効ではない場合です。

      • WINDOW_UPDATEフレームでウィンドウを2^31-1を超える値にする:ストリームごとのフロー制御ウィンドウは2^31-1を超えることはできません。これを超過するインクリメントが指示された場合、サーバーはこれをストリームエラーとみなし、RST_STREAMでストリームをリセットします。
      • クライアントがストリームを閉じた後にHEADERSフレームを送信する:END_STREAMフラグを設定することで、クライアントはそれ以上HTTPメッセージフレームを送信しないことを示します。この後にHEADERSフレームが来ると、ストリームの状態マシンに違反するため、ストリームエラーとなり、RST_STREAMが送信されます。
      • クライアントがストリームを閉じた後にDATAフレームを送信する:これもHEADERSフレームと同様に、END_STREAMフラグの後にDATAフレームが送信された場合にストリームエラーとなり、RST_STREAMが送信されます。
  • ストリーム状態とリセット:
    RFCのストリーム状態マシンによれば、RST_STREAM(クライアントまたはサーバーのどちらから開始されたかにかかわらず)によってストリームは即座に「クローズ済み」状態に遷移します。そして、「クローズ済み」のストリームはMAX_CONCURRENT_STREAMSの制限にカウントされません。これにより、攻撃者はサーバーの同時実行制限をバイパスし、無制限の作業を押し付けることが可能になります。

  • なぜバックエンド処理が継続するのか:
    この攻撃が強力である理由は、ストリームがリセットされた後でもバックエンドでの処理が続くという、HTTP/2サーバーにおける一般的な実装動作にあります。

    • プロキシの例:HTTP/2プロキシがHTTP/1.1のオリジンサーバーにリクエストを転送する一般的なデプロイメントを考えてみましょう。HTTP/1.1にはリクエストキャンセルの概念がないため、HTTP/2側でストリームがリセットされても、HTTP/1.1バックエンドは処理を継続します。HTTP/2モジュールはストリームがクローズされたことを認識し、バックエンドから送られてくるレスポンスを破棄しますが、バックエンドは既にリソースを消費しています。
    • 単一サーバーの例:ほとんどのサーバーは、ワイヤープロトコルを扱う「プロトコルモジュール」と、レスポンスを計算する「バックエンド」の2層で構成されています。プロトコルモジュールはフレームをプロトコルに依存しないHTTPリクエスト構造に変換し、バックエンドに渡します。バックエンドは通常、そのリクエストがHTTP/1.1で来たのかHTTP/2で来たのかを認識しません。これは設計上のものであり、HTTP/2がHTTP/1.1のメッセージセマンティクスを維持したため、アプリケーションコードの変更が不要だったためです。
    • 根本原因:したがって、根本原因は、プロトコルとバックエンド間の内部APIがHTTP/2よりはるか以前に設計されており、一般的にキャンセルセマンティクスを含んでいないことにあります。HTTP/2フロントエンドを導入してもこれらのAPIは変更されなかったため、リセット後もバックエンドの作業が継続してしまうのです。

Step4. MadeYouResetのインパクト

MadeYouResetの攻撃は、サーバーに多大な負荷をかけ、サービス拒否状態を引き起こします。

  • 無制限の同時実行作業:
    この脆弱性により、攻撃者は最小限のリソースで、ターゲットサーバー上で実質的に無制限の同時実行作業を発生させることができます。これは従来のDDoS攻撃よりもはるかに少ない帯域幅と計算能力でサーバーを圧倒することを可能にします。
  • 完全なサービス拒否とメモリ不足:
    ほとんどのHTTP/2準拠の実装がこの影響を受けます。多くのサーバーが完全なサービス拒否状態に陥り、中にはメモリ不足(OOM)でクラッシュするものも見られました。
  • 非対称性:
    リクエストの送信にかかるコストと、レスポンスの計算にかかるコストの非対称性が、この攻撃の有効性を高めています。
  • フロントエンドへの負荷:
    たとえ一部のリクエストがバックエンドでの重い処理に至らなかったとしても、ストリームオブジェクトの作成と破棄、フレームのパース、状態遷移の進行、HPACKの維持、クリーンアップといったHTTP/2フロントエンドでの処理オーバーヘッドだけでも、大規模な場合は深刻なパフォーマンス低下やDoSを引き起こす可能性があります。

Step5. MadeYouResetの緩和策

MadeYouResetの根本的な問題は、ストリームがリセットされた後もバックエンドの処理が継続することにあるため、これに対処するための3つの主要な方法が考えられます。

  1. エンドツーエンドのキャンセル
    ストリームがリセットまたはキャンセルされた際に、バックエンドの作業も停止するようにすることです。これは最も自然な解決策に聞こえますが、実装は非常に困難で、場合によっては信頼性の確保が不可能です。非同期の境界、スレッドプール、サードパーティライブラリを越えてキャンセルを伝播させる必要があり、多くの操作は協調的キャンセルに対応していません。誤って実装すると、オープンハンドル、不完全な書き込み、メモリリークなど、様々な問題を引き起こす可能性があります。
  2. バックエンドでのアクティブなHTTPリクエストの制限
    HTTP/2のMAX_CONCURRENT_STREAMSとは別に、処理中のHTTPリクエスト数に対する独自の制限を設けることです。これにより、HTTP/2ストリームがリセットされても、リクエストは依然としてカウントされます。しかし、これもアーキテクチャの変更を必要とすることが多く、複雑です。
  3. HTTP/2におけるサーバー起因のストリームリセットの制限
    各接続におけるサーバー起因のRST_STREAMフレームの数に上限を設けるという、手軽に実装できる対策です。通常のクライアントがサーバー側でストリームエラーを引き起こすことは稀であるため、小さな上限でも十分効果的です。この対策はバックエンドの動作を変更するものではありませんが、MadeYouResetが利用する特定の経路をブロックします。HTTP/2のストリーム状態マシンによれば、クライアント起因とサーバー起因の2つのリセット方式しか存在しないため、この対策はMadeYouResetを効果的に阻止すると考えられています。

MadeYouResetは、HTTP/2の設計上の特性と、HTTP/2以前のAPI設計が組み合わさって生まれた脆弱性です。この攻撃の非対称性により、サーバーは少ないリソースの攻撃者によって容易に過負荷状態に陥る可能性があります。そのため、HTTP/2サーバーを運用する組織は、直ちにベンダーの勧告を確認し、利用可能なパッチを適用してこの重大な脆弱性を軽減することが強く推奨されています。

背景情報

  • HTTP/2プロトコルには、サーバーの過負荷を防ぐための「MAX_CONCURRENT_STREAMS」パラメータが設けられている
  • 2023年の「Rapid Reset」攻撃は、この機能を悪用して大規模なDDoS攻撃を行っていた
  • その後、サーバーがリセットされたリクエストを数えるように対策が講じられていた