The world of cybersecurity is a complex and ever-evolving landscape, and the recent discovery of the HTTP/2 Bomb vulnerability is a prime example of why. This exploit, which affects major web servers like NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora, has the potential to cause significant disruption and downtime for organizations and individuals alike. But what makes this vulnerability particularly fascinating is the way it leverages the very features of HTTP/2 that are designed to improve performance and security.
HTTP/2 is a protocol that enables faster and more efficient communication between web servers and clients. It does this by introducing a dedicated header compression algorithm called HPACK, which reduces the size of headers by an average of 30%. This is achieved through Huffman encoding, which compresses request and response metadata. HPACK is also designed to be resilient to attacks like CRIME, which can leak authentication cookies from compressed headers.
However, the HTTP/2 Bomb vulnerability takes advantage of a different aspect of HTTP/2. It exploits the way HPACK compresses headers, turning a single byte on the wire into a full header allocation on the server. This is achieved by chaining together two known techniques: a compression bomb and a Slowloris-style hold. The compression bomb stuffs a large value into the table and references it repeatedly, while the Slowloris-style hold is a zero-byte flow-control window that keeps the server from ever freeing any of it.
What makes this vulnerability particularly insidious is the way it amplifies the impact of the attack. While the classic bomb stuffs a large value into the table and references it repeatedly, the HTTP/2 Bomb variant goes the other way. The header is nearly empty, and the amplification comes from the per-entry bookkeeping the server allocates around it. This means that the decoded-size limit never fires because there's almost nothing to decode.
In a hypothetical attack scenario, a home computer on a 100Mbps connection has the potential to render a vulnerable server inaccessible within seconds. What's more, a single client can consume and hold 32GB of server memory against Apache HTTPD and Envoy in about 20 seconds. This is a significant increase in the potential impact of a denial-of-service (DoS) attack, and it highlights the importance of addressing this vulnerability.
The good news is that there are mitigations available to counter the HTTP/2 Bomb vulnerability. For NGINX, upgrading to version 1.29.8+ adds the maxheaders directive with a default of 1000, or disabling HTTP/2 with http2 off. For Apache HTTPD, the fix is available in modhttp2 v2.0.41, or you can set Protocols http/1.1 to disable HTTP/2. However, for Microsoft IIS, Envoy, and Cloudflare Pingora, no patch is available as of writing.
The deeper miss, according to the researchers at Calif, is that the spec frames memory risk purely as an amplification ratio, and ratio is only half the equation. A 70:1 amplifier is harmless if the memory is freed when the request completes. However, HTTP/2 lets the client hold the connection open almost for free, pinning every allocated byte for as long as they like. This means that the amplification ratio is not the only factor to consider when assessing the impact of a memory-exhaustion attack.
In conclusion, the HTTP/2 Bomb vulnerability is a significant threat to the security and stability of web servers. It highlights the importance of staying vigilant and proactive in the face of emerging threats. As organizations and individuals, we must continue to invest in cybersecurity measures and stay informed about the latest developments in the field. Only then can we hope to mitigate the impact of such vulnerabilities and ensure the safety and resilience of our digital infrastructure.
