HTTP/2 "Rapid Reset" DDOS attack

iworx

iworx

Verified User
Joined
Nov 21, 2006
Messages
98
Location
Belgium
Google's release :
cloud.google.com

How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack | Google Cloud Blog

Learn how the new DDoS attack technique Rapid Reset works, and how to mitigate it
cloud.google.com cloud.google.com

Cloudflare's blog :
blog.cloudflare.com

HTTP/2 Zero-Day Vulnerability Results in Record-Breaking DDoS Attacks

The “HTTP/2 Rapid Reset” attack exploits a weakness in the HTTP/2 protocol to generate enormous, hyper-volumetric DDoS attacks. Cloudflare has mitigated a barrage of these attacks in recent months, including an attack three times larger than any previous attack we’ve observed
blog.cloudflare.com blog.cloudflare.com

@DirectAdmin Support Any known updates underway + release schedule?
 
From a knowledgeable resource :
  • NGINX Open Source has patches
  • NGINX Plus - mitigation but no patch yet
  • Apache has patches
These should be released today. I hope DirectAdmin / CustomBuild will update today/tomorrow too.
 
iworx said:
From what I've read/learned - everything that handles HTTP/2 is affected. I expect communication / patches from them all anytime soon.
Click to expand...
just got an update from LS at Slack: "Good news: LiteSpeed`s HTTP/2 implementation is NOT vulnerable to Rapid Reset! more details on the way later.

Edit / Update: LiteSpeed servers are NOT subject to the attack

blog.litespeedtech.com

Rapid Reset HTTP/2 Vulnerablilty ⋆ LiteSpeed Blog

LiteSpeed web server products cannot be overloaded by the Rapid Reset HTTP/2 Vulnerability. Learn why.
blog.litespeedtech.com blog.litespeedtech.com

We’re happy to report that LiteSpeed servers are NOT subject to the attack, and this comes down to our unique HTTP/2 implementation. When LiteSpeed Enterprise became the first web server to offer HTTP/2 support, we did so with an implementation that was written from the ground up with security in mind. LiteSpeed HTTP/2 effectively fends off many attacks that other implementations may struggle against.
With LiteSpeed HTTP/2:
  • New streams are placed in internal priority queues
  • Streams are processed based on priority at the ending edge of one I/O event
  • When there are massive amounts of new streams with a RST_STREAM frame, closely followed within the same I/O event, the stream is immediately discarded from the priority queue without further processing.
  • If an attacker delays the RST_STREAMframe after the stream is processed, the effects are twofold:
    1. The attack will be slowed down
    2. The non-configurable 100 concurrent stream limit will be reached, and the connection will be closed by the server.
There is nothing you need to do to protect yourself from this type of attack.

The maximum impact a Rapid Reset attack can have on a LiteSpeed server is the wasting of CPU cycles in handling the stream’s frames, and creating and recycling the stream object.

What we intend to do​

We plan to further enhance our HTTP/2 implementation to specifically target this attack based on its traffic pattern. Once detected, we’ll eliminate the waste of CPU cycles with IP blocking.

An emergency security patch is not required this time.
 
Last edited:
Nginx 1.25.3

Changes with nginx 1.25.3 24 Oct 2023

*) Change: improved detection of misbehaving clients when using HTTP/2.

*) Feature: startup speedup when using a large number of locations.
Thanks to Yusuke Nojima.

*) Bugfix: a segmentation fault might occur in a worker process when
using HTTP/2 without SSL; the bug had appeared in 1.25.1.

*) Bugfix: the "Status" backend response header line with an empty
reason phrase was handled incorrectly.

*) Bugfix: memory leak during reconfiguration when using the PCRE2
library.
Thanks to ZhenZhong Wu.

*) Bugfixes and improvements in HTTP/3.
Click to expand...
 
You must log in or register to reply here.
Back
Top