Bug 1759697 (CVE-2019-18277)

Summary: CVE-2019-18277 haproxy: HTTP request smuggling issue with transfer-encoding header containing an obfuscated "chunked" value
Product: [Other] Security Response Reporter: Pedro Sampaio <psampaio>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: afox, bmontgom, bperkins, carl, dominik.mierzejewski, eparis, hhorak, jburrell, jeremy, jokerman, jorton, nstielau, pavloos, rabdulra, rohara, rschiron, sponnaga
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: haproxy 2.0.6, haproxy 1.8.22 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-07 22:31:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1761283, 1761284, 1761285, 1761287, 1761291, 1761292, 1765642, 1765643, 1826597    
Bug Blocks: 1759692    

Description Pedro Sampaio 2019-10-08 20:52:23 UTC
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

Comment 1 Mark Cooper 2019-10-14 02:00:23 UTC
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.

Comment 5 Riccardo Schirone 2019-10-24 15:43:51 UTC
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.

Comment 7 Riccardo Schirone 2019-10-25 15:28:49 UTC
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.

Comment 9 Riccardo Schirone 2019-10-25 15:35:12 UTC
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

Comment 13 Riccardo Schirone 2019-10-25 16:27:31 UTC
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.

Comment 14 Tomas Hoger 2020-04-01 20:57:17 UTC
Fix for haproxy 1.8:

http://git.haproxy.org/?p=haproxy-1.8.git;a=commitdiff;h=3bd4bbdb9f54c18856aeb66b4b9f4a698973d3d3

Applied in version 1.8.22.

Comment 15 errata-xmlrpc 2020-04-07 19:43:11 UTC
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

Comment 16 Product Security DevOps Team 2020-04-07 22:31:49 UTC
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

Comment 18 errata-xmlrpc 2020-04-28 15:44:45 UTC
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

Comment 19 errata-xmlrpc 2020-05-04 10:17:38 UTC
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

Comment 20 errata-xmlrpc 2020-05-26 07:35:24 UTC
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

Comment 22 Nick Tait 2020-07-04 22:11:18 UTC
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.