The HTTP/2 Bomb: A Remote Denial-of-Service Threat to Major Web Servers
The world of cybersecurity is abuzz with the discovery of a critical vulnerability known as the HTTP/2 Bomb. This exploit targets major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora, posing a significant risk to online services. The HTTP/2 Bomb is a clever combination of two known techniques: a compression bomb and a Slowloris-style hold, which together create a powerful denial-of-service (DoS) attack.
A Deep Dive into HTTP/2 and HPACK
To understand the HTTP/2 Bomb, we need to delve into the world of HTTP/2 and its header compression scheme, HPACK. HTTP/2 is a protocol designed to improve the efficiency and speed of web communication. HPACK is a dedicated header compression algorithm that reduces the size of request and response metadata by 30% on average, using Huffman encoding. This compression is crucial for optimizing data transfer, but it also introduces vulnerabilities.
The HTTP/2 Bomb exploits HPACK by targeting its header compression mechanism. When a byte on the wire becomes a full header allocation on the server, the server's resources can be quickly exhausted. This is achieved by chaining together a compression bomb and a Slowloris-style hold, creating an amplification effect.
The Classic Bomb and Its Variants
The HTTP/2 Bomb draws inspiration from previous vulnerabilities, such as the HPACK Bomb (CVE-2016-6581), a memory exhaustion issue in Apache httpd's HTTP/2 implementation. Other vulnerabilities include crafted CONTINUATION frames (CVE-2016-8740) and worker-thread starvation (CVE-2016-1546) in Apache HTTP Server. However, the HTTP/2 Bomb introduces a unique twist by exploiting the per-entry bookkeeping allocated by the server, leading to a different kind of amplification.
The Power of the HTTP/2 Bomb
What makes the HTTP/2 Bomb particularly dangerous is its potential for rapid and severe impact. In a hypothetical attack scenario, a home computer with a 100Mbps connection can render a vulnerable server inaccessible within seconds. Even more alarming, a single client can consume and hold 32GB of server memory against Apache HTTPD and Envoy in just 20 seconds. This highlights the need for immediate action to mitigate the risk.
Mitigation Strategies
To counter the HTTP/2 Bomb, web server administrators should take the following actions:
- NGINX: Upgrade to version 1.29.8 or higher, which introduces the
max_headersdirective with a default limit of 1000. Alternatively, disable HTTP/2 with thehttp2 offdirective. - Apache HTTPD: Update to mod_http2 v2.0.41 or set
Protocols http/1.1to disable HTTP/2. - Microsoft IIS, Envoy, and Cloudflare Pingora: No patches are available at the time of writing, but monitoring and proactive security measures are essential.
A Missed Opportunity in the Specification
The HTTP/2 specification's focus on memory risk as an amplification ratio is a critical oversight. While a 70:1 amplifier may be harmless if memory is freed upon request completion, HTTP/2's ability to keep connections open indefinitely allows clients to pin every allocated byte, turning a potential amplification into a full-blown attack.
Conclusion and Future Outlook
The HTTP/2 Bomb is a stark reminder of the ongoing arms race between cybersecurity researchers and attackers. As web servers continue to adopt HTTP/2, it is crucial to stay vigilant and proactive in addressing vulnerabilities. The cybersecurity community must collaborate to develop robust solutions and ensure the safety and stability of online services. This incident highlights the need for continuous monitoring, timely updates, and a deep understanding of emerging threats in the ever-evolving landscape of web security.
