A flaw was found in haproxy before version 2.0.6. In legacy mode, messages featuring a transfer-encoding header missing the "chunked" value was not being correctly rejected. The impact was limited but if combined with "http-reuse always", it could be used as an help to construct a content smuggling attack against a vulnerable component employing a lenient parser which would ignore the content-length header as soon as it sees a transfer-encoding one, without even parsing it. References: https://www.mail-archive.com/haproxy@formilux.org/msg34926.html https://nathandavison.com/blog/haproxy-http-request-smuggling
Version packaged with Openshift (haproxy-1.8.x) is vulnerable. However, the following option must be set in the haproxy.cfg: http-reuse always OpenShift does not set this configuration for HAProxy.
Preconditions for the attack to be possible: - option `http-reuse always` is in the haproxy.conf file (see https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#4.2-http-reuse); - the legacy HTTP decoder is in use. On versions of haproxy before 2.0.5, like the ones shipped in RHEL 6, 7, and 8, this is the default; - the backend must support HTTP keep-alive (aka HTTP connection reuse); - the backend server needs to have a bug that makes it consider the HTTP header `Transfer-Encoding: chunked` even when this is not perfectly compliant with the specification (e.g. `Transfer-Encoding:\x0bchunked`). This is not the case with Web Servers like httpd or nginx.
Upstream patch: https://git.haproxy.org/?p=haproxy-2.0.git;a=commit;h=196a7df44d8129d1adc795da020b722614d6a581
haproxy keeps a pool of HTTP connection to the backend server which can be reused based on the `http-reuse` option value. When `http-reuse always` option is used, haproxy can send the first request of a session to an existing backend connection. This flaw can be used to poison one of those backend connections, thus allowing an attacker to do a request to the backend server and leave additional data in the backend connection that will be interpreted as part of a following request coming from a victim user.
Mitigation: - Reconsider the use of `http-reuse always` if possible - Disable HTTP Keep-Alive (also called HTTP Connection reuse) in the backend - Fix the backend server to correctly parse Transfer-Encoding/Content-Length headers
Functions http_wait_for_request() and http_wait_for_response() do not correctly check if the Transfer-Encoding HTTP header has the "chunked" value. So an HTTP header like `Transfer-Encoding: foobar` would not be rejected. This lack of validation makes the HTTP request smuggling attack possible.
Fix for haproxy 1.8: http://git.haproxy.org/?p=haproxy-1.8.git;a=commitdiff;h=3bd4bbdb9f54c18856aeb66b4b9f4a698973d3d3 Applied in version 1.8.22.
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 3.11 Via RHSA-2020:1287 https://access.redhat.com/errata/RHSA-2020:1287
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-18277
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:1725 https://access.redhat.com/errata/RHSA-2020:1725
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.4 Via RHSA-2020:1936 https://access.redhat.com/errata/RHSA-2020:1936
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS Via RHSA-2020:2265 https://access.redhat.com/errata/RHSA-2020:2265
Statement: To exploit this vulnerability a vulnerable backend server is required. In particular the server should incorrectly parse the Transfer-Encoding HTTP header. This issue did not affect the versions of haproxy as shipped with Red Hat Enterprise Linux 6, and 7 as they did not include support for `http-reuse` option.