In the realm of web security, vulnerabilities within protocols can lead to significant disruptions. The HTTP/2 protocol, while offering enhanced performance over its predecessor, is not immune to such weaknesses as we observed last year with the HTTP/2 Rapid Reset attack. Another notable example of this is the recently disclosed HTTP/2 Continuation vulnerability. This particular flaw, unlike the HTTP/2 Rapid Reset, stems not from the protocol's design but from its implementation, posing a risk of resource depletion or server crashes that could result in a denial-of-service (DoS) condition on affected services. What makes this vulnerability especially concerning is that it can be exploited with a relatively small number of specially crafted HTTP/2 frames, making it accessible to a wide range of potential malicious actors, including those with limited technical sophistication. This contrasts with the Rapid Reset attack, a zero-day vulnerability exploited in the wild, whereas the HTTP/2 Continuation Flood was identified by a security researcher prior to any known exploitation.
HTTP/2 Rapid Reset Attack
On October 10, 2023, Google disclosed a previously unknown application-layer DDoS attack technique used by innovative attackers the company dubbed HTTP/2 Rapid Reset. The method leverages a protocol vulnerability in the specification of the multiplexing feature in HTTP/2, allowing attackers to increase the rate of their application-layer Web DDoS attacks significantly. This attack was made possible by abusing some features of the HTTP/2 protocol and server implementation details (see “HTTP/2 Rapid Reset Attack Technique Observed in the Wild” for more information). Because the attack abuses an underlying weakness in the HTTP/2 protocol any vendor that has implemented HTTP/2 would have been subject to the attack.
HTTP/2 Protocol Scrutiny
History has shown us that the emergence of a vulnerability in a new application or protocol often captures the security community's attention, drawing its collective gaze to what can be described as the latest 'shiny object' in cybersecurity. This shift in focus brings about a wave of renewed scrutiny. Echoing this pattern, security researcher Barket Nowotarski, in his technical analysis, shares that the discovery of the HTTP/2 "Rapid Reset" attack in October 2023 spurred him to delve deeper into the security dimensions of HTTP/2. Motivated by this newfound vulnerability, he embarked on a journey to examine HTTP/2 through the lens of a security analyst thoroughly.
HTTP/2 Continuation Frames
Like HTTP/1, HTTP/2 utilizes header fields, consisting of a name and at least one value, to facilitate communication within HTTP request and response messages and in server push mechanisms. These header fields are organized into header lists, which can contain any number of header fields. These header lists are compressed into a header block for transmission over a network using HTTP header compression techniques. This compressed block is then segmented into one or more sequences of octets known as header block fragments. These fragments are then dispatched in the payloads of HEADERS, PUSH_PROMISE, or CONTINUATION frames, ensuring efficient and orderly data transmission.
In HTTP/2, the CONTINUATION frame (type=0x9) is crucial in extending a series of header block fragments. This flexibility allows for any number of CONTINUATION frames to be transmitted, provided they follow either a HEADERS, PUSH_PROMISE, or another CONTINUATION frame that does not signal the end of headers and are all part of the same data stream.
The Continuation Attack
The method of attack involves creating an endless header sequence by initially dispatching a HEADERS frame followed by a perpetual series of CONTINUATION frames filled with nonsensical header data. This tactic aims to exploit a vulnerability where HTTP/1.1 servers typically defend against such threats by severing connections once the header size reaches a certain threshold or if request/header timeouts are triggered.
Over recent months, Barket Nowotarski has scrutinized numerous implementations and found inadequate protection against these attacks in many HTTP/2 servers, including prominent ones such as Apache httpd, Envoy, and various HTTP/2 packages or codecs. The absence or flawed implementation of protective measures can, depending on the server's architecture, result in significant CPU or memory drain, or even lead to server crashes due to an assertion failure. Nowotarski has compiled a list of projects confirmed to be susceptible to this vulnerability and has documented the corresponding CVE IDs for each identified issue here.
An Implementation vulnerability
In section 10.5, titled "Denial-of-Service Considerations," of RFC9113, it's highlighted that maintaining an HTTP/2 connection can require a more substantial allocation of resources compared to an HTTP/1.1 connection, mainly due to the implementation of header compression and flow control mechanisms. These features necessitate the reservation of resources to manage an expanded state. The document advises that implementations should offer settings to limit the memory usage dedicated to these functionalities. Specifically, section 10.5.1, "Limits on Header Block Size," discusses how a server that receives a header block exceeding its processing capacity may respond with an HTTP 431 (Request Header Fields Too Large) status code, as per RFC6585. Although there's no explicit mention of handling CONTINUATION frames that arrive without the concluding END_HEADERS flag, it's implied that implementations should account for various scenarios that might result in unchecked resource consumption and address these situations appropriately.
Mitigation and Protection
Servers found to be susceptible to this vulnerability require immediate patching and updating. In scenarios where production servers cannot be promptly updated and are potentially exposed to this exploit, deploying a secure application-level HTTP/2 proxy that is immune to continuation floods can act as a protective barrier. This setup helps intercept and neutralize malicious traffic before it can trigger a denial-of-service (DoS) scenario. Users of Radware Cloud Services benefit from built-in protection against such threats, necessitating no additional measures on their part. Radware has released a knowledge base article along with a comprehensive product matrix offering in-depth details on the vulnerability coverage for its range of products and services here.
References