Netflix has identified several denial of service (DoS) flaws in numerous implementations of HTTP/2, a popular network protocol that underpins large parts of the web. Exploiting them could make servers grind to a halt.
HTTP/2 is the latest flavour of HTTP, the application protocol that manages communication between web servers and clients. Released in 2015, HTTP/2 introduced several improvements intended to make sessions faster and more reliable.
- HTTP header compression. In previous HTTP versions, only the body of a request could be compressed, even though for small web pages the headers, which often include data such as cookies and are always sent in text format, could be bigger than the body.
- Multiplexed streams and binary packets. This made it easier to download multiple items in parallel, speeding up rendering of web pages made up of many parts.
- Server Push. This means the server can send across cacheable information that the client might need later, even if it hasn’t been requested yet.
Features like these can help reduce latency and improve search engine rankings. The problem is that more complexity means more opportunity for bugs.
Netflix explains this in its writeup of the issue:
The algorithms and mechanisms for detecting and mitigating “abnormal” behavior are significantly more vague and left as an exercise for the implementer. From a review of various software packages, it appears that this has led to a variety of implementations with a variety of good ideas, but also some weaknesses.
There are eight of those weaknesses, all with their own separate CVE number and nickname.
Some flaws are reminiscent of other non-HTTP/2 DoS attacks.
Ping flooding, for example, is well-known and understood in DDoS circles – it’s where you keep on asking a server, “Are you there?” even though you know the answer perfectly well and are asking simply to make the server waste time doing work to no purpose.
In the HTTP/2 version (CVE-2019-9512), repeated ping requests may force the server to queue up responses, fall behind and even stop responding.
There are three other flooding attacks.
The reset flood (CVE-2019-9514) opens multiple streams and sends invalid requests on all of them to generate a
RST_STREAM response. Servers are supposed to use
RST_STREAM frames to terminate a session when a browser cancels a file download or navigates away from a page. A server forced to process lots of them can suffer a denial of service condition.
A settings flood, dubbed CVE-2019-9515, sends a stream of
SETTINGS frames to the peer. The server is supposed to reply to every
SETTINGS request, so this causes a similar situation to the aforementioned ping flood.
The third type of flood is an empty frames attack (CVE-2019-9518). This sends a constant stream of frames with an empty payload, and the server wastes time handling them.
There are several other attacks that rely on manipulating the server by creating invalid, unusual or pointless packets.
The data dribble attack (CVE-2019-9511) uses multiple streams in a way that forces the server to queue up data in small chunks. This can chew through CPU and memory resources.
The resource loop attack (CVE-2019-9513) constantly switches the priority of multiple streams, putting needless load on the server’s priority-shuffling code.
The zero-length headers leak attack (CVE-2019-9516) sends data headers flagged as empty, even though it takes memory to send and receive the data block that says, “Here is an empty item.” If the server keeps the as-received headers in memory, rather than dumping them because they ultimately decode to nothing, an attacker may be able to chew through memory on the server.
Finally, an internal data buffering attack (CVE-2019-9517) asks the server for a large file, but does’t open the necessary data channel required by the protocol for the server to reply with the data. If the server loads up some or all of the requested data into internal buffers but then has nowhere to send it, it may bog down due to the increased load on memory.
This is an important issue for the overall health of the web because 25% of websites use HTTP/2.
A list of affected vendors is shown in the associated CERT note, together with links to vendor websites for updated information.