By Bennett Pursell, Ecosystem Strategist and Omkhar Arasaratnam, General Manager, OpenSSF
On October 10, several technology providers disclosed a 0-day vulnerability enumerated as CVE-2023-44487, Rapid Reset. Rapid Reset is a vulnerability in how the HTTP/2 protocol was abused to create the most significant attempted denial of service against several major technology providers. This can disrupt business and cause significant financial losses across industries because an attack could take a company’s website offline.
A study from Cloudflare earlier this year concluded that almost 65% of the browser traffic on the internet was HTTP/2. If your business has a webpage and your web servers are vulnerable to Rapid Reset, you could see an immediate impact on your business. Much like log4shell a couple of years ago, Rapid Reset can plague our industry for years as vendors gradually apply fixes to critical business applications, embedded systems, and appliances.
The HTTP/2 protocol allows multiple streams to be created over the same TCP connection. This enables web pages to be rendered more efficiently than HTTP/1.1. In a Rapid Reset attack, the attacker opens multiple new streams and quickly sends RST_FRAMEs to close them. This creates a heavy load on the server as it requires a lot of processing to create and rapidly destroy streams. The compute capacity required by the server is much higher than that needed by the attacker. This could allow the attacker to cause the server to become overloaded and unresponsive with little effort.
Since the initial attack, several similar variants have emerged, all of which take slightly different approaches to opening streams and sending RST_FRAMEs, resulting in the same outcome. Until patches are available, an appropriate mitigation strategy would be to close TCP connections with high create/RST_FRAME ratios. The “right” ratio will depend highly on the application and its clients.
The good news is that many large technology companies such as Google and Amazon have already implemented mitigations for their customers. However, organizations that manage their own internet presence may have further work to do to secure their infrastructure against Rapid Reset.
At the Secure Open Source Software (SOSS) Summit earlier this year, OpenSSF and our public and private sector partners advocated for SBOM-based triage and incident response plans. As maintainers roll out patches for their webservers to address Rapid Reset, having an accurate SBOM inventory will help remediate your most important assets first.
Security vulnerabilities like Looney Tunables, Rapid Reset, and the forthcoming cURL vulnerabilities will continue to be discovered. That is why the OpenSSF continues to invest in convening efforts between the public sector, private sector, and the community to ensure open source software is secure for everyone. If helping the community to secure open source software is interesting to you, we invite you to join our efforts at the OpenSSF.