Rapid Reset HTTP/2 Vulnerablilty
Here’s the situation with the Rapid Reset HTTP/2 vulnerability in a nutshell:
- CVE-2023-44487 was published yesterday. It outlines a vulnerability in the HTTP/2 protocol, which allows DDoS attacks that are massive in scale
- LiteSpeed server products (including LiteSpeed Web Server Enterprise, LiteSpeed Web ADC and OpenLiteSpeed) are NOT vulnerable to this line of attack
Read on for more information about the Rapid Reset HTTP/2 vulnerability, and why you don’t have to worry about your LiteSpeed-powered sites.
How Rapid Reset Works
After an HTTP/2 connection is established, the client may choose to cancel the stream by sending an RST_STREAM
The vulnerability is exploited when a large number of streams are canceled quickly over a single connection, before any subsequent streams arrive. The server’s concurrent stream count is not incremented, the maximum is never reached despite all of the activity, and the server becomes overloaded.
How it affects LiteSpeed products
Unlike Cloudflare, Google, Microsoft, Amazon, F5, and others, who have been working together on a solution for more than a month, we only learned of this vulnerability with everyone else yesterday, when the CVE was published.
Despite the short notice, we got to work immediately to learn how (or if) the Rapid Reset vulnerability could be leveraged against LiteSpeed’s HTTP/2 implementation.
“Because the attack abuses an underlying weakness in the HTTP/2 protocol, we believe any vendor that has implemented HTTP/2 will be subject to the attack.”
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 - If an attacker delays the
RST_STREAM- The attack will be slowed down
- 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.
Conclusion
“We, along with Google and AWS, have disclosed the attack method to web server vendors who we expect will implement patches.”
– Cloudflare’s Rapid Reset Technical Breakdown
This was not our experience, sadly. We wish we had been notified in advance about this event. After all, we serve more than 12% of the top sites on the internet! It’s disappointing that we were not afforded the luxury of time that the other web server vendors were presumably given to address the potential impacts for our clients.
Luckily, LiteSpeed servers are minimally affected by the Rapid Reset vulnerability. But can we be sure that will be the case when future vulnerabilities are discovered?
We have tried to contact the proper people about this, to no avail. If you were involved in the coordination of the CVE, please get in touch via our info@litespeedtech.com email and help us ensure we are kept in the loop in the future. Thank you.
Comments