HTTP/2「MadeYouReset」脆弱性によりサービス拒否(DoS)攻撃が可能に

概要:HTTP/2における新たなDoS脆弱性「MadeYouReset」

多数のHTTP/2実装で発見された重大な脆弱性により、脅威アクターが強力なサービス拒否(DoS)および分散型サービス拒否(DDoS)攻撃を実行できる危険なプロトコルレベルの脆弱性が露呈しました。CVE-2025-8671として追跡され、通称「MadeYouReset」と呼ばれるこの脆弱性は、HTTP/2の仕様と実際のサーバー実装との間の根本的な不一致を悪用します。

テルアビブ大学のセキュリティ研究者であるGal Bar Nahum氏、Anat Bremler-Barr氏、Yaniv Harel氏によって発見されたこの脆弱性は、長年にわたりインターネットを悩ませてきた同様の攻撃の懸念すべき進化を示しています。

技術的詳細:MadeYouResetの仕組み

この脆弱性は、サーバーが送信するストリームリセットを悪用することで機能します。これにより、サーバーが処理していると認識しているアクティブなHTTP/2ストリームの数と、実際にバックエンドで処理されているHTTPリクエストの数との間に不一致が生じます。攻撃者が不正なフレームやフロー制御エラーを使用してサーバーリセットを迅速にトリガーすると、プロトコルはこれらのリセットされたストリームを閉じられ、非アクティブであると見なします。しかし、バックエンドサーバーはストリームリセットにもかかわらずリクエストの処理を継続するため、攻撃者は単一の接続で無制限の数の同時HTTP/2リクエストを処理させることが可能になります。

この根本的なアーキテクチャ上の見落としは、ストリームキャンセル機能をリソース枯渇のための武器に変えてしまいます。

HTTP/2はストリームキャンセル機能を導入し、クライアントとサーバーの両方が通信中の任意の時点でストリームを即座に閉じられるようにしました。プロトコルには、セッションあたりのアクティブなストリーム数を制限することで、まさにこの種の攻撃を防ぐように設計されたSETTINGS_MAX_CONCURRENT_STREAMSパラメータが含まれています。理論的には、この保護策は悪意のあるストリームリクエストによってサーバーが過負荷になるのを防ぐはずです。

しかし、この脆弱性は重大な実装上の欠陥を悪用します。攻撃者によって開始されたストリームをサーバーがリセットすると、プロトコルのアカウンティングシステムはこれらのストリームを閉じられたものとしてマークし、同時ストリーム制限の対象から外します。その間、バックエンド処理は中断されることなく継続されます。攻撃者はリセットリクエストを繰り返し送信することで、サーバーを操作し、安全パラメータが許容するよりも指数関数的に多くのリクエストを処理させます。プロトコルはこれらを閉じられた非アクティブなストリームと見なしますが、サーバーのバックエンドはそれらを処理し続け、最終的に深刻なリソース枯渇につながります。実装の詳細によっては、被害者は壊滅的なCPU過負荷や壊滅的なメモリ枯渇を経験する可能性があります。

広範な影響と対応策

MadeYouResetは、クライアントが送信するストリームリセットを悪用したCVE-2023-44487(通称「Rapid Reset」)と酷似しています。この脆弱性クラスの継続性は、HTTP/2の実装がストリームリセットのライフサイクル管理を適切に考慮できていないことを示唆しています。

アドバイザリによると、Apache Tomcat、Mozilla、Red Hat、SUSE Linux、Netty、gRPC、Fastly、Varnish Software、Eclipse Foundation、AMPHPなど、多数の主要ベンダーやプロジェクトが影響を受けています。これらのベンダーの多くは、すでにこの脆弱性に対処するパッチまたは公式声明をリリースしています。Apache Tomcatは、この脆弱性の実装を説明するためにCVE-2025-48989を具体的に受け取りました。

Computer Emergency Response Team Coordination Center(CERT/CC)は、ベンダーに対し、サーバーから送信されるRST_STREAMフレームの数とレートに対するより厳格な制限の実装と、HTTP/2実装の包括的なレビューを推奨しています。

影響を受けるHTTP/2インフラストラクチャを運用している組織は、直ちにパッチを適用することを優先すべきです。この脆弱性のDDoSの可能性は、重要なインフラストラクチャに対する大規模な攻撃を企てる脅威アクターにとって特に魅力的です。セキュリティチームは、ベンダーのアドバイザリを参照し、利用可能なパッチを適用し、パッチが展開されるまでリセットフレームに対する追加のレート制限制御の実装を検討する必要があります。


元記事: https://gbhackers.com/denial-of-service-attacks/