The Imperva HTTP/2 Vulnerability Report and NGINX

On August 3, Imperva – an Internet security company – announced four potential security vulnerabilities in the HTTP/2 protocol, and issued a detailed report evaluating a number of web servers against these vulnerabilities.

As shown in the table (from page 19 of the Imperva report), NGINX 1.9.9 performed comparatively well in Imperva’s tests, and was not affected by three of the four potential vulnerabilities. Attempts to exploit the remaining vulnerability, “Slow Read”, caused a resource leakage in NGINX and ultimately allowed a denial-of-service attack against HTTP/2 services.

The fault was reported to NGINX, and was resolved promptly in the NGINX 1.9.12 and NGINX Plus R9 releases. We are pleased to confirm that none of the current versions of NGINX software – NGINX Plus, NGINX Open Source ‘mainline’, or NGINX Open Source ‘stable’ – are vulnerable to any of the potential attacks described by Imperva.

If you have implemented HTTP/2 and are using a version of our software earlier than NGINX 1.9.12 or NGINX Plus R9, update your software. HTTP/2 is a complex and relatively new protocol, so it is wise to run the latest software version at all times.

We suggest you review our best practices for tuning NGINX and NGINX Plus. The tuning in a default Linux configuration is often quite conservative, and changing some parameters can increase the capacity of your NGINX or NGINX Plus system.

The Problem

As of August 2016, HTTP/2 is currently in use on roughly 9% of all websites, including very popular sites such as FaceBook, Google, and Wikipedia. Content delivery network (CDN) providers that use NGINX and NGINX Plus often include HTTP/2 as part of their offerings.

The complex design of HTTP/2 means there are many possible avenues that researchers can explore to seek out design or implementation weaknesses. The Imperva reports describes four potential vulnerabilities in HTTP/2:

• Slow Read Attack (CVE-2016-1546), which affects Apache HTTP Server 2.4.17 and 2.4.18. This is the only one of the four vulnerabilities that affected NGINX; see page 11 of the report. The National Vulnerability Database (NVD) listing is CVE-2016-1546.
• HTTP/2 Stream Multiplexing (CVE-2016-0150), which affects Microsoft Windows 10 Gold and 1511. The NVD listing is CVE-2016-0150.
• Dependency and Priority, which affects versions of nghttpd before 1.7.0 and Apache HTTP Server 2.4.18 and earlier. The report states that the vulnerability was fixed in nghttpd 1.7.0 “as part of a more general memory cleanup issue (CVE-2015-8659)“. The NVD listing is (CVE-2015-8659).
• HPACK Bomb (CVE-2016-1544 and CVE-2016-2525), which affects versions of nghttpd before 1.7.1 and versions of Wireshark before 2.0.2 and 1.12.10. The NVD listing is CVE-2016-2525; the listing for CVE-2016-1544 is marked as reserved and contains no information.

When Imperva tested various web servers to see if they exhibited vulnerabilities, a variation of their “Slow Read” test exposed a resource‑leakage bug in NGINX and NGINX Plus. This resource leakage ultimately resulted in a denial of service.

NGINX and NGINX Plus are not generally vulnerable to “Slow Read” attacks (often known as Slowloris). Imperva’s test case helped us to isolate a previously reported resource leakage bug. We were then able to address this error case by adding additional timeouts and guards to ensure that HTTP/2 resources were closed and released correctly, and we were able to verify that these measures are effective.

Mitigation

We strongly recommend upgrading to the latest version of NGINX and NGINX Plus, especially if you have implemented HTTP/2 and are using NGINX 1.9.11 or earlier, or NGINX Plus R8 or earlier. The resource leakage bug exposed by Imperva’s test case is not exhibited by NGINX 1.9.12 and later or NGINX Plus R9 and later.

NGINX and NGINX Plus provide effective ways to defeat the relevant vulnerability described in the Imperva report, and upgrading to the latest release of either product eliminates the vulnerability entirely.

To reduce your site’s vulnerability in general, we also recommend that you take the actions outlined in our post on mitigating DDoS attacks, including:

• Limiting the rate of requests from any single user (the limit_req directive)
• Limiting the number of connections that can be opened by a single client (the limit_conn directive)
• Closing connections more quickly with more aggressive timeouts

If you have any questions, please comment on this post – or, if you are an NGINX Plus subscriber, don’t hesitate to contact our support team for assistance.