What is HTTP/2?
An HTTP/2 is an application-layer protocol running on top of a TCP connection. HTTP/2 is a major revision of the HTTP protocol.

HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and this result in excessive latency.

HTTP/2 improves upon the widely used HTTP/1.1 standard by providing data compression of HTTP headers, pipelining of requests, fixing the head-of-line blocking and multiplexing multiple requests over a single TCP connection. It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance and reduces latency.

HTTP/2 Connection
Each endpoint is required to send a connection preface data to establish the HTTP/2 connection. The client connection begins with a 24-byte magic preface: “PRI * HTTP/2.0\x0d\x0a\x0d\x0aSM\x0d\x0a\x0d\x0a”. Once the HTTP/2 connection is established, endpoints can begin exchanging frames. All HTTP/2 frames begin with a fixed 9-byte header followed by a variable-length payload.

HTTP/2 Frame:

Length: The length of the frame payload

Type: The 8-bit type of the frame ((e.g. 0x0 DATA, 0x1 HEADERS, 0x5 PUSH_PROMISE, 0x6 PING)

Flags: An 8-bit field reserved for boolean flags specific to the frame type.

R: A reserved 1-bit field.

Stream Identifier: A stream identifier to which this frame belong, expressed as an unsigned 31-bit integer.

HTTP/2 Vulnerabilities:Netflix has discovered several resource exhaustion vulnerabilities affecting a variety of third-party HTTP/2 implementations. These attack vectors can be used to launch Denial of Service attacks against servers that support HTTP/2 communication.

CVE-2019-9511 : Data Dribble
The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.

CVE-2019-9512 : Ping Flood
The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.

CVE-2019-9513 : Resource Loop
The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU, potentially leading to a denial of service.

CVE-2019-9514 : Reset Flood
The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RST_STREAM frames from the peer. Depending on how the peer queues the RST_STREAM frames, this can consume excess memory, CPU, or both, potentially leading to a denial of service.

CVE-2019-9515 : Settings Flood
The attacker sends a stream of SETTINGS frames to the peer. Since the RFC requires that the peer reply with one acknowledgement per SETTINGS frame, an empty SETTINGS frame is almost equivalent in behavior to a ping. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both, potentially leading to a denial of service.

CVE-2019-9516 : 0-Length Headers Leak
The attacker sends a stream of headers with a 0-length header name and 0-length header value, optionally Huffman encoded into 1-byte or greater headers. Some implementations allocate memory for these headers and keep the allocation alive until the session dies. This can consume excess memory, potentially leading to a denial of service.

CVE-2019-9517 : Internal Data Buffering
The attacker opens the HTTP/2 window so the peer can send without constraint; however, they leave the TCP window closed so the peer cannot actually write (many of) the bytes on the wire. The attacker then sends a stream of requests for a large response object. Depending on how the servers queue the responses, this can consume excess memory, CPU, or both, potentially leading to a denial of service.

CVE-2019-9518 : Empty Frame Flooding
The attacker sends a stream of frames with an empty payload and without the end-of-stream flag. These frames can be DATA, HEADERS, CONTINUATION and/or PUSH_PROMISE. The peer spends time processing each frame disproportionate to attack bandwidth. This can consume excess CPU, potentially leading to a denial of service.

Remediation:

Affected vendors are Microsoft, Akamai, Amazon, Apache, Apple, Cloudflare, Envoy, Facebook, Go Programming Language, gRPC, Netty, nghttp2, nginx, Node.js, Synology, Twisted & Ubuntu.

Please find the matrix of affected products and vulnerabilities here.

Apply the latest updates from the HTTP/2 implementers. 

To be fully protected from the vulnerabilities, Microsoft recommends configuring the server to limit the number of HTTP/2 packets accepted. Refer to the respective vendor advisory regarding these vulnerabilities.

SonicWall Capture Labs Threat Research team provides protection against this exploit with the following signatures:

IPS: 14362 Windows HTTP/2 Server DoS (AUG 19)
IPS: 14366 Windows HTTP/2 Server DoS (AUG 19) 2
IPS: 14375 Windows HTTP/2 Server DoS 4 (AUG 19)
IPS: 14373 HTTP/2 SERVER Informational 
IPS: 14374 Windows HTTP/2 PING Informational

SonicWall Capture Labs Threat Research team continue to monitor any attempts to exploit the recently patched http/2 vulnerabilities.