Bug 1189549 - (CVE-2021-39240) VUL-0: CVE-2021-39240: haproxy: Domain parts in ":scheme" and ":path"
(CVE-2021-39240)
VUL-0: CVE-2021-39240: haproxy: Domain parts in ":scheme" and ":path"
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
unspecified
Other Other
: P3 - Medium : Minor
: ---
Assigned To: Peter Varkoly
Security Team bot
https://smash.suse.de/issue/307473/
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-08-18 06:33 UTC by Robert Frohl
Modified: 2021-10-21 09:04 UTC (History)
2 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Frohl 2021-08-18 06:33:49 UTC
2) CVE-2021-39240: Domain parts in ":scheme" and ":path"

The ":scheme" HTTP/2 header field contains the scheme that prefixes the
request URI, typically "http" or "https". ":path" contains the part that
is local to the target host, and that usually starts with the "/". By
appending a part of a request to ":scheme" or by prepending a part of a
domain name to ":path", it is possible to make haproxy and a backend
server see a different authority or URL prefix. Please note that this
only affects HTTP/2 servers on versions 2.2 and above. These versions
are indeed capable of passing an absolute URI from end to end, while
earlier versions were limited to origin URIs. In addition, HTTP/2
requests are always forwarded in origin form to HTTP/1 backend servers
(i.e. they do not have a scheme nor authority parts). As such HTTP/1
servers are safe and only HTTP/2 servers are exposed.

What happens is that on the entry point, the :scheme, :authority and :path
fields are concatenated to rebuild a full URI that is then passed along the
chain, but the Host header is set from :authority before this concatenation
is performed. As such, the Host header field used internally may not always
match the authority part of the recomposed URI. Examples:

   H2 request
     :method:   "GET"
     :scheme:   "http://localhost/?orig=";
     :authority "example.org"
     :path:     "/"

 or:

   H2 request
     :method:   "GET"
     :scheme:   "http"
     :authority "example.org"
     :path:     ".local/"

An internal Host header will be build with "example.org" then the complete
URI will become "http://localhost/?orig=example.org/"; in the first example,
or "http://example.org.local/"; in the second example, and this URI will be
used to build the HTTP/2 request on the server side, dropping the unneeded
Host header field. In HTTP/1 there is no such issue as the URI is dropped
and the Host is kept. Thus if the configuration contains some routing rules
based on the Host header field, a target HTTP/2 server might receive a
different :authority than the one that was expected to be routed there.

A workaround consists in rewriting the URI as itself before processing the
Host header field, which will have for effect to resynchronize the Host
header field with the recomposed URI, making sure both haproxy and the
backend server will always see the same value:

      http-request set-uri %[url]


References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-39240
http://www.debian.org/security/-1/dsa-4960
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39240
https://git.haproxy.org/?p=haproxy.git;a=commit;h=a495e0d94876c9d39763db319f609351907a31e8
https://git.haproxy.org/?p=haproxy.git;a=commit;h=4b8852c70d8c4b7e225e24eb58258a15eb54c26e
https://www.mail-archive.com/haproxy@formilux.org/msg41041.html
Comment 1 Robert Frohl 2021-08-18 06:36:00 UTC
only relevant for openSUSE
Comment 2 Peter Varkoly 2021-10-14 11:22:44 UTC
The actual package in devel project (server:http) and openSUSE:Factory do already contains the fixes.
-----
Tue Aug 17 15:50:01 UTC 2021 - mrueckert@suse.de
..
..
  * BUG/MAJOR: h2: verify that :path starts with a '/' before concatenating it
  * BUG/MAJOR: h2: verify early that non-http/https schemes match the valid syntax

 Do you think we need update for openLeap15.2/3?
Comment 3 Robert Frohl 2021-10-19 09:26:43 UTC
(In reply to Peter Varkoly from comment #2)
>  Do you think we need update for openLeap15.2/3?

Leap inherits from SLE, so all resolved from our side.
Comment 4 Peter Varkoly 2021-10-21 09:04:16 UTC
Fixed