Bug 1759697 (CVE-2019-18277) - CVE-2019-18277 haproxy: HTTP request smuggling issue with transfer-encoding header containing an obfuscated "chunked" value
Summary: CVE-2019-18277 haproxy: HTTP request smuggling issue with transfer-encoding h...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-18277
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1761283 1761284 1761285 1761287 1761291 1761292 1765642 1765643 1826597
Blocks: 1759692
TreeView+ depends on / blocked
 
Reported: 2019-10-08 20:52 UTC by Pedro Sampaio
Modified: 2021-02-16 21:18 UTC (History)
17 users (show)

Fixed In Version: haproxy 2.0.6, haproxy 1.8.22
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-07 22:31:49 UTC


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:1287 0 None None None 2020-04-07 19:43:13 UTC
Red Hat Product Errata RHSA-2020:1725 0 None None None 2020-04-28 15:44:46 UTC
Red Hat Product Errata RHSA-2020:1936 0 None None None 2020-05-04 10:17:43 UTC
Red Hat Product Errata RHSA-2020:2265 0 None None None 2020-05-26 07:35:26 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.