CVE-2020-11100 haproxy: malformed HTTP/2 requests can lead to out-of-bounds writes

Executive Summary

Red Hat is aware of a flaw in the way HAProxy processed certain HTTP/2 request packets.  An attacker could send crafted HTTP/2 request packets which cause memory corruption, leading to a crash or remote arbitrary code execution with the permissions of the user running HAProxy. 

This issue has been assigned CVE-2020-11100 with a severity impact of Critical.

Affected Products

Red Hat Products Affected by CVE-2020-11100

Updates for Affected Products

Technical Details and Background

HAProxy is a TCP/HTTP reverse proxy which is designed for high availability environments.  HAProxy is typically deployed in front of a cluster of application servers and dispatches incoming requests to one of the servers, resulting in increased performance and high availability.  When deployed with a website, HAProxy can optionally use the HTTP/2 protocol for more efficient use of network resources.

This is a flaw in the way HTTP/2 request packets are handled by HAProxy. 

HAProxy packages shipped with Red Hat Enterprise Linux 6 and 7 do not contain support for HTTP/2; therefore, they are not affected by this flaw.

All OpenShift Container Platform 4 versions through 4.3 contain the vulnerable code. However, exploitation requires setting ROUTER_USE_HTTP2 in the OpenShift Ingress Operator, which is not currently possible. The impact of this vulnerability, is therefore, reduced in OCP 4.x before version 4.4 to low.

OpenShift Container Platform 3.11 added a configuration option to ose-haproxy-router that made enabling HTTP/2 support easy. However, it is not enabled by default on that version.

Mitigation

Security errata for affected products are released as early as possible; please consult the table above for availability details. Customers requiring a solution before fixes are available, or seeking an alternative solution, should assess the mitigation described below.

On Red Hat Enterprise Linux 8, HAProxy is confined by SELinux, which should mitigate remote arbitrary code execution.  

This issue can be mitigated by not enabling support for HTTP/2 protocol. The default HAProxy configurations shipped with Red Hat products have HTTP/2 disabled, but it is common to alter these defaults in a customer environment.

You can check if HTTP/2 is enabled by searching your HAProxy configuration files for a line containing 'h2'.  Typically this looks something like:
    bind :443 ssl crt pub.pem alpn h2,http/1.1

To mitigate this vulnerability in OpenShift Container Platform 3.11, keep HTTP/2 disabled as it is by default, or disable if you have it previously enabled.

You can also verify if HTTP/2 support is enabled on a given server using the curl command line tool as follows.  Note that in both cases, the client offers HTTP/2, but the server only accepts it in the first case.  Replace the hostname with your own.

$ curl -v --http2 https://h2-enabled.example.com/ 2>&1 >/dev/null | grep ALPN 
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server accepted to use h2

$ curl -v --http2 https://h2-not-enabled.example.com/ 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

** Note that if the backend server is serving HTTP/2 responses and HAProxy is using passthrough mode, this test will show HTTP/2 in use.  A negative result from this test can be relied on.  A positive test may need to be confirmed by ensuring a closer examination of the configuration to confirm more specifics of where the response is being received.  If you get a positive result and you think you’re not using HTTP/2, check the route configuration for passthrough mode.

A good URL to test for OpenShift Container Platform 3.11 is the “Cluster Console” (in the openshift-console project) because it doesn’t use a passthrough route. Note that this route is distinct from the “Application Console” (in the openshift-web-console project), which isn't proxied by the router pod.

$ curl -v --http2 https://console.apps.example.com 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

The API server in OpenShift Container Platform 3.11 is an example of a pass through route.  Even though this is behind haproxy, the fact it’s a passthrough means the connection terminates inside the pod in a golang binary that has HTTP/2 enabled.  The server detected in this case is inside the apiserver pod, and not the vulnerable haproxy in the router pod.

$ curl -v --http2 https://apiserver-kube-service-catalog.apps.example.com 2>&1 >/dev/null | grep ALPN
* ALPN, offering h2
* ALPN, offering http/1.1
* ALPN, server did not agree to a protocol

Acknowledgements

Red Hat thanks the HAProxy project for reporting this issue. Upstream acknowledges Felix Wilhelm from Google Project Zero as the original reporter of this issue.

References

Google Project Zero Disclosure

Google Project Zero 

HAProxy team blog