Bugzilla – Bug 1189549
VUL-0: CVE-2021-39240: haproxy: Domain parts in ":scheme" and ":path"
Last modified: 2021-10-21 09:04:16 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:
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]
only relevant for openSUSE
The actual package in devel project (server:http) and openSUSE:Factory do already contains the fixes.
Tue Aug 17 15:50:01 UTC 2021 - firstname.lastname@example.org
* 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?
(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.