原文はこちら。
The original article was written by Daniel Kec (Java Developer at Oracle).
https://medium.com/helidon/helidon-and-http-2-rapid-reset-vulnerability-d470526f4dac
CVE-2023–44487: HTTP/2 protocol Rapid Reset vulnerability
今夏の終わりに、インターネット史上最大のDDoS攻撃が起こりました。あまり世間に知られることなく、攻撃は3大クラウド・プロバイダー（Cloudflare、Google、AWS）をターゲットにしたものでした。
しばらくして10月10日、DDoS攻撃を可能にしたHTTP/2プロトコルの新たなゼロデイ脆弱性（HTTP/2 Rapid-Reset）がCVE-2023-44487として公開されました。
CVE-2023-44487
https://nvd.nist.gov/vuln/detail/CVE-2023-44487
この脆弱性はHTTP/2仕様そのものに存在するため、HTTP/2プロトコルをサポートするランタイムの設計次第で、この攻撃は多かれ少なかれ脅威となるものです。
攻撃はかなり単純です： HTTP/2クライアントは、サーバーほど多くのリソースを使うことなく、1つの接続で何百万、何千万のリクエスト（ストリーム）を合法的に作成できます。一方サーバーは仕様上、それらを受け取るための手続きに、大量のリソースを突っ込む必要があります。
“Why nobody thought of that?”
この仕様では、ランタイムにMAX_CONCURRENT_STREAMS設定で自己防衛する手段を与えています。サーバーはクライアントに対し、一度に開くことができるストリー ムの数を指示するだけでよいのです(5.1.2)。
5.1.2. Stream Concurrency
https://httpwg.org/specs/rfc9113.html#rfc.section.5.1.2
問題は、RST_STREAMフレームを使用することで、クライアントがいつでもすぐにストリームをキャンセルできる権利も、この仕様で与えられていることです。そこが問題なのです(6.4)。
RST_STREAM
https://httpwg.org/specs/rfc9113.html#rfc.section.6.4
クライアントはサーバーに新しいストリームをセットアップさせ、ストリームを即座にリセット/キャンセルすることができるため（これが「Rapid-Reset Attack」の名前の由来です）、サーバーとクライアントの間で大きな非対称性が発生します。サーバーはヘッダーを解析し、新しいストリームのために必要なリソースを割り当て、それを解放する必要がありますが、それに対してクライアントはそれほどのことをする必要はありません。クライアントはその節約した時間で、即座にリセット・フレームを伴って、同じヘッダーを何度も送信することができます。
このシンプルさにより、Rapid-Resetは非常に簡単に実行でき、仕様のルールを破らなければ防御が難しくなっています。
Helidon
Helidonのすべてのバージョンで、HTTP/2をサポートするには明示的に有効にする必要があります。Helidonはバージョン4.x、3.x、実験的に2.xと1.xでHTTP/2をサポートしています。
Helidon 4
Helidon 4はデフォルトでHTTP/2サポートを無効にしています。HTTP/2を有効にするには、1つの依存関係が必要です。
<dependency>
<groupId>io.helidon.webserver</groupId>
<artifactId>helidon-webserver-http2</artifactId>
</dependency>
Helidon 4 HTTP/2サーバーは、リリース4.0.0でrapid reset用のトークンバケットが修正され、閾値に達するとGO_AWAYを送信して接続を閉じます。
Helidon 4.0.0
https://github.com/helidon-io/helidon/releases/tag/4.0.0
HTTP/2サーバーのデフォルトで、rapid reset攻撃からの保護が有効になっていますので、何もする必要はありません。
デフォルトでは、10秒間に100回のrapid resetを許可しています。以下の設定で、rapid reset防御を微調整できます。
server:
port: 8080
host: localhost
protocols:
http_2:
rapid-reset-check-period: PT10S # 10 seconds in ISO_8601 format
max-rapid-resets: 100 # max 100 requests with rapid resets
SEの場合、APIを使ってプログラミングで構成できます。
Server server = Server.builder()
.addProtocol(Http2Config.builder()
.rapidResetCheckPeriod(Duration.of(10, ChronoUnit.SECONDS))
.maxRapidResets(100)
.build())
.host("localhost")
.port(8080)
.routing(...)
.build()
.start();
Helidon 3
Helidon 3ではデフォルトで HTTP/2 サポートを無効化しています。有効化するには1個の依存関係が必要です。
<dependency>
<groupId>io.helidon.webserver</groupId>
<artifactId>helidon-webserver-http2</artifactId>
</dependency>
Helidon 4とは異なり、 Helidon 3.xはNettyライブラリ上に構築されており、Netty 4.1.100.Finalのアップストリームパッチに依存しています。
Merge pull request from GHSA-xpw8-rcwv-8f8p
https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61
Netty 4.1.100.Final released
https://netty.io/news/2023/10/10/4-1-100-Final.html
パッチ適用済みバージョンのNettyでは、30秒のタイムウィンドウあたり200回のリセットが可能です。パッチが適用されたバージョンの Netty へのアップグレードは、Helidon 3.2.3 リリースに含まれています。
Helidon 3.2.3
https://github.com/helidon-io/helidon/releases/tag/3.2.3
⚠️ サーバーでHTTP/2を有効にしているのであればHelidon 3.2.3 へのアップグレードを速やかに実施してください。
Helidon 2 and 1
Helidon 2と1の両バージョンは、デフォルトでHTTP/2サポートが無効になっています。HTTP/2を有効にするには、実験的な機能を有効にする必要があります。
server:
port: 8080
host: localhost
experimental:
http2:
enable: true
max-content-length: 16384
Helidonのバージョン2と1はNettyライブラリの上に構築されており、Netty 4.1.100.Finalのアップストリームパッチに依存しています。パッチ適用済みバージョンへのNettyのアップグレードは、Helidon 2.6.4リリースに含まれています。
Merge pull request from GHSA-xpw8-rcwv-8f8p
https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61
Netty 4.1.100.Final released
https://netty.io/news/2023/10/10/4-1-100-Final.html
Helidon 2.6.4
https://github.com/helidon-io/helidon/releases/tag/2.6.4
⚠️ サーバーで HTTP/2 が有効になっている場合は、できるだけ早く Helidon 2.6.4 にアップグレードしてください！
Conclusion
HelidonのすべてのバージョンでHTTP/2をサポートするには、明示的に有効にする必要があることをお忘れなく。
10月10日、インターネットの大部分は、脆弱性のあるHTTP/2インフラにできるだけ早くパッチを当てたり、アップデートしたりするために、時を刻み始めました。
HTTP/2を使用している場合は、できるだけ早くHelidonのパッチ適用済みバージョンにアップデートしてください。
Logico Inside 