dgit.raspbian.org Git - haproxy.git/log

Merge version 2.2.9-2+rpi1+deb11u5 and 2.2.9-2+deb11u6 to produce 2.2.9-2+rpi1+deb11u6

Merge haproxy (2.2.9-2+deb11u6) import into refs/heads/workingbranch

DOC: clarify the handling of URL fragments in requests

Origin: https://git.kernel.org/linus/b5062da485e78f4448a617a0f8b67dc5b23065d5

We indicate in path/pathq/url that they may contain '#' if the frontend
is configured with "option accept-invalid-http-request", and that option
mentions the fragment as well.

(cherry picked from commit 7ab4949ef107a7088777f954de800fe8cf727796)
[ad: backported as a companion to BUG/MINOR: h1: do not accept '#' as
part of the URI component]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 965fb74eb180ab4f275ef907e018128e7eee0e69)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit e9903d6073ce9ff0ed8b304700e9d2b435ed8050)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit c47814a58ec153a526e8e9e822cda6e66cef5cc2)
[wt: minor ctx adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 3706e1754b925e56951b604cce63f3bb290ed838)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name DOC-clarify-the-handling-of-URL-fragments-in-request.patch

REGTESTS: http-rules: verify that we block '#' by default for normalize-uri

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=dbf47600f63ffe161ce08d2f0faef7e0deb32b6e

Since we now block fragments by default, let's add an extra test there
to confirm that it's blocked even when stripping it.

(cherry picked from commit 4d0175b54b2b4eeb01aa6e31282b0a5b0d7d8ace)
[ad: backported to test conformance of BUG/MINOR: h1: do not accept '#'
as part of the URI component]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit b3f26043df74c661155566a0abd56103e8116078)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 41d161ccbbfa846b4b17ed0166ff08f6bf0c3ea1)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit b6b330eb117d520a890e5b3cd623eaa73479db1b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 73b9b13ac2654ef5384789685e3d65ca5f2f880a)
[wt: rewrote the test for 2.2 without normalize-uri and called it
fragments-in-uri]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name REGTESTS-http-rules-verify-that-we-block-by-default-.patch

BUG/MINOR: h2: reject more chars from the :path pseudo header

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=e0c9008874b89621449f7ff3e9bc6db4e94fac6d

This is the h2 version of this previous fix:

    BUG/MINOR: h1: do not accept '#' as part of the URI component

In addition to the current NUL/CR/LF, this will also reject all other
control chars, the space and '#' from the :path pseudo-header, to avoid
taking the '#' for a part of the path. It's still possible to fall back
to the previous behavior using "option accept-invalid-http-request".

This patch modifies the request parser to change the ":path" pseudo header
validation function with a new one that rejects 0x00-0x1F (control chars),
space and '#'. This way such chars will be dropped early in the chain, and
the search for '#' doesn't incur a second pass over the header's value.

This should be progressively backported to stable versions, along with the
following commits it relies on:

     REGTESTS: http-rules: add accept-invalid-http-request for normalize-uri tests
     REORG: http: move has_forbidden_char() from h2.c to http.h
     MINOR: ist: add new function ist_find_range() to find a character range
     MINOR: http: add new function http_path_has_forbidden_char()
     MINOR: h2: pass accept-invalid-http-request down the request parser

(cherry picked from commit b3119d4fb4588087e2483a80b01d322683719e29)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 462a8600ce9e478573a957e046b446a7dcffd286)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 648e59e30723b8fd4e71aab02cb679f6ea7446e7)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit c8e07f2fd8b5462527f102f7145d6027c0d041da)
[wt: minor ctx adjustments]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit af232e47e6264122bed3681210b054ff38ec8de8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name BUG-MINOR-h2-reject-more-chars-from-the-path-pseudo-.patch

BUG/MINOR: h1: do not accept '#' as part of the URI component

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=178cea76b1c9d9413afa6961b6a4576fcb5b26fa
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-45539

Seth Manesse and Paul Plasil reported that the "path" sample fetch
function incorrectly accepts '#' as part of the path component. This
can in some cases lead to misrouted requests for rules that would apply
on the suffix:

    use_backend static if { path_end .png .jpg .gif .css .js }

Note that this behavior can be selectively configured using
"normalize-uri fragment-encode" and "normalize-uri fragment-strip".

The problem is that while the RFC says that this '#' must never be
emitted, as often it doesn't suggest how servers should handle it. A
diminishing number of servers still do accept it and trim it silently,
while others are rejecting it, as indicated in the conversation below
with other implementers:

   https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0070.html

Looking at logs from publicly exposed servers, such requests appear at
a rate of roughly 1 per million and only come from attacks or poorly
written web crawlers incorrectly following links found on various pages.

Thus it looks like the best solution to this problem is to simply reject
such ambiguous requests by default, and include this in the list of
controls that can be disabled using "option accept-invalid-http-request".

We're already rejecting URIs containing any control char anyway, so we
should also reject '#'.

In the H1 parser for the H1_MSG_RQURI state, there is an accelerated
parser for bytes 0x21..0x7e that has been tightened to 0x24..0x7e (it
should not impact perf since 0x21..0x23 are not supposed to appear in
a URI anyway). This way '#' falls through the fine-grained filter and
we can add the special case for it also conditionned by a check on the
proxy's option "accept-invalid-http-request", with no overhead for the
vast majority of valid URIs. Here this information is available through
h1m->err_pos that's set to -2 when the option is here (so we don't need
to change the API to expose the proxy). Example with a trivial GET
through netcat:

  [08/Aug/2023:16:16:52.651] frontend layer1 (#2): invalid request
    backend <NONE> (#-1), server <NONE> (#-1), event #0, src 127.0.0.1:50812
    buffer starts at 0 (including 0 out), 16361 free,
    len 23, wraps at 16336, error at position 7
    H1 connection flags 0x00000000, H1 stream flags 0x00000810
    H1 msg state MSG_RQURI(4), H1 msg flags 0x00001400
    H1 chunk len 0 bytes, H1 body len 0 bytes :

    00000  GET /aa#bb HTTP/1.0\r\n
    00021  \r\n

This should be progressively backported to all stable versions along with
the following patch:

    REGTESTS: http-rules: add accept-invalid-http-request for normalize-uri tests

Similar fixes for h2 and h3 will come in followup patches.

Thanks to Seth Manesse and Paul Plasil for reporting this problem with
detailed explanations.

(cherry picked from commit 2eab6d354322932cfec2ed54de261e4347eca9a6)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 9bf75c8e22a8f2537f27c557854a8803087046d0)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 9facd01c9ac85fe9bcb331594b80fa08e7406552)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 832b672eee54866c7a42a1d46078cc9ae0d544d9)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit e5a741f94977840c58775b38f8ed830207f7e4d0)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name BUG-MINOR-h1-do-not-accept-as-part-of-the-URI-compon.patch

MINOR: h2: pass accept-invalid-http-request down the request parser

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=d87aeb80c45cc504274188f0e5048148f3c4f2ff

We're adding a new argument "relaxed" to h2_make_htx_request() so that
we can control its level of acceptance of certain invalid requests at
the proxy level with "option accept-invalid-http-request". The goal
will be to add deactivable checks that are still desirable to have by
default. For now no test is subject to it.

(cherry picked from commit d93a00861d714313faa0395ff9e2acb14b0a2fca)
[ad: backported for following fix : BUG/MINOR: h2: reject more chars
from the :path pseudo header]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit b6be1a4f858eb6602490c192235114c1a163fef9)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 26fa3a285df0748fc79e73e552161268b66fb527)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 014945a1508f43e88ac4e89950fa9037e4fb0679)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit f86e994f5fb5851cd6e4f7f6b366e37765014b9f)
[wt: adjusted ctx in h2.h]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name MINOR-h2-pass-accept-invalid-http-request-down-the-r.patch

MINOR: http: add new function http_path_has_forbidden_char()

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=921f79588c6180c406e88236228a5be1c5c67c55

As its name implies, this function checks if a path component has any
forbidden headers starting at the designated location. The goal is to
seek from the result of a successful ist_find_range() for more precise
chars. Here we're focusing on 0x00-0x1F, 0x20 and 0x23 to make sure
we're not too strict at this point.

(cherry picked from commit 30f58f4217d585efeac3d85cb1b695ba53b7760b)
[ad: backported for following fix : BUG/MINOR: h2: reject more chars
from the :path pseudo header]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit b491940181a88bb6c69ab2afc24b93a50adfa67c)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit f7666e5e43ce63e804ebffdf224d92cfd3367282)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit c699bb17b7e334c9d56e829422e29e5a204615ec)
[wt: adj minor ctx in http.h]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 0f57ac20b046b70275192651d7b6c978032e6a36)
[wt: adj minor ctx in http.h]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name MINOR-http-add-new-function-http_path_has_forbidden_.patch

MINOR: ist: Add istend() function to return a pointer to the end of the string

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=b12ab9c04a896a90383dbaf5c808a6d9a26cde98

istend() is a shortcut to istptr() + istlen().

(cherry picked from commit cf26623780bdd66f4fff4154d0e5081082aff89b)
[wt: needed for next fix]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name MINOR-ist-Add-istend-function-to-return-a-pointer-to.patch

MINOR: ist: add new function ist_find_range() to find a character range

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=cbac8632582d82a1452ccb3fe3c38196e8ad9f45

This looks up the character range <min>..<max> in the input string and
returns a pointer to the first one found. It's essentially the equivalent
of ist_find_ctl() in that it searches by 32 or 64 bits at once, but deals
with a range.

(cherry picked from commit 197668de975e495f0c0f0e4ff51b96203fa9842d)
[ad: backported for following fix : BUG/MINOR: h2: reject more chars
from the :path pseudo header]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 451ac6628acc4b9eed3260501a49c60d4e4d4e55)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 3468f7f8e04c9c5ca5c985c7511e05e78fe1eded)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit b375df60341c7f7a4904c2d8041a09c66115c754)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit edcff741698c9519dc44f3aa13de421baad7ff43)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name MINOR-ist-add-new-function-ist_find_range-to-find-a-.patch

BUG/MAJOR: http: reject any empty content-length header value

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=e8ba5e106444fc78558f4ff26e9ce946f89216f4
Bug-Debian: https://bugs.debian.org/1043502
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-40225

The content-length header parser has its dedicated function, in order
to take extreme care about invalid, unparsable, or conflicting values.
But there's a corner case in it, by which it stops comparing values
when reaching the end of the header. This has for a side effect that
an empty value or a value that ends with a comma does not deserve
further analysis, and it acts as if the header was absent.

While this is not necessarily a problem for the value ending with a
comma as it will be cause a header folding and will disappear, it is a
problem for the first isolated empty header because this one will not
be recontructed when next ones are seen, and will be passed as-is to the
backend server. A vulnerable HTTP/1 server hosted behind haproxy that
would just use this first value as "0" and ignore the valid one would
then not be protected by haproxy and could be attacked this way, taking
the payload for an extra request.

In field the risk depends on the server. Most commonly used servers
already have safe content-length parsers, but users relying on haproxy
to protect a known-vulnerable server might be at risk (and the risk of
a bug even in a reputable server should never be dismissed).

A configuration-based work-around consists in adding the following rule
in the frontend, to explicitly reject requests featuring an empty
content-length header that would have not be folded into an existing
one:

http-request deny if { hdr_len(content-length) 0 }

The real fix consists in adjusting the parser so that it always expects a
value at the beginning of the header or after a comma. It will now reject
requests and responses having empty values anywhere in the C-L header.

This needs to be backported to all supported versions. Note that the
modification was made to functions h1_parse_cont_len_header() and
http_parse_cont_len_header(). Prior to 2.8 the latter was in
h2_parse_cont_len_header(). One day the two should be refused but the
former is also used by Lua.

The HTTP messaging reg-tests were completed to test these cases.

Thanks to Ben Kallus of Dartmouth College and Narf Industries for
reporting this! (this is in GH #2237).

(cherry picked from commit 6492f1f29d738457ea9f382aca54537f35f9d856)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit a32f99f6f991d123ea3e307bf8aa63220836d365)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 65921ee12d88e9fb1fa9f6cd8198fd64b3a3f37f)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit d17c50010d591d1c070e1cb0567a06032d8869e9)
[wt: applied to h2_parse_cont_len_header() in src/h2.c instead]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ba9afd2774c03e434165475b537d0462801f49bb)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name BUG-MAJOR-http-reject-any-empty-content-length-heade.patch

BUG/MAJOR: fcgi: Fix uninitialized reserved bytes

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=18575ba4e5057afdb80cc06135272889ae1fa2d1
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-0836

The output buffer is not zero-initialized. If we don't clear reserved
bytes, fcgi requests sent to backend will leak sensitive data.

This patch must be backported as far as 2.2.

(cherry picked from commit 2e6bf0a2722866ae0128a4392fa2375bd1f03ff8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit db03179fee55c60a92ce6b86a0f04dbb9ba0328b)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit f988992d16f45ef03d5bbb024a1042ed8123e4c5)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 0dc4cdc276d4a0e3347b7c3c4aedca2a2e0ab428)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 0c86fce8028d409de4181e82eec967cfb1e6268e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 2.2-BUG-MAJOR-fcgi-Fix-uninitialized-reserved-bytes.patch

BUG/CRITICAL: http: properly reject empty http header field names

The HTTP header parsers surprizingly accepts empty header field names,
and this is a leftover from the original code that was agnostic to this.

When muxes were introduced, for H2 first, the HPACK decompressor needed
to feed headers lists, and since empty header names were strictly
forbidden by the protocol, the lists of headers were purposely designed
to be terminated by an empty header field name (a principle that is
similar to H1's empty line termination). This principle was preserved
and generalized to other protocols migrated to muxes (H1/FCGI/H3 etc)
without anyone ever noticing that the H1 parser was still able to deliver
empty header field names to this list. In addition to this it turns out
that the HPACK decompressor, despite a comment in the code, may
successfully decompress an empty header field name, and this mistake
was propagated to the QPACK decompressor as well.

The impact is that an empty header field name may be used to truncate
the list of headers and thus make some headers disappear. While for
H2/H3 the impact is limited as haproxy sees a request with missing
headers, and headers are not used to delimit messages, in the case of
HTTP/1, the impact is significant because the presence (and sometimes
contents) of certain sensitive headers is detected during the parsing.
Thus, some of these headers may be seen, marked as present, their value
extracted, but never delivered to upper layers and obviously not
forwarded to the other side either. This can have for consequence that
certain important header fields such as Connection, Upgrade, Host,
Content-length, Transfer-Encoding etc are possibly seen as different
between what haproxy uses to parse/forward/route and what is observed
in http-request rules and of course, forwarded. One direct consequence
is that it is possible to exploit this property in HTTP/1 to make
affected versions of haproxy forward more data than is advertised on
the other side, and bypass some access controls or routing rules by
crafting extraneous requests.  Note, however, that responses to such
requests will normally not be passed back to the client, but this can
still cause some harm.

This specific risk can be mostly worked around in configuration using
the following rule that will rely on the bug's impact to precisely
detect the inconsistency between the known body size and the one
expected to be advertised to the server (the rule works from 2.0 to
2.8-dev):

  http-request deny if { fc_http_major 1 } !{ req.body_size 0 } !{ req.hdr(content-length) -m found } !{ req.hdr(transfer-encoding) -m found } !{ method CONNECT }

This will exclusively block such carefully crafted requests delivered
over HTTP/1. HTTP/2 and HTTP/3 do not need content-length, and a body
that arrives without being announced with a content-length will be
forwarded using transfer-encoding, hence will not cause discrepancies.
In HAProxy 2.0 in legacy mode ("no option http-use-htx"), this rule will
simply have no effect but will not cause trouble either.

A clean solution would consist in modifying the loops iterating over
these headers lists to check the header name's pointer instead of its
length (since both are zero at the end of the list), but this requires
to touch tens of places and it's very easy to miss one. Functions such
as htx_add_header(), htx_add_trailer(), htx_add_all_headers() would be
good starting points for such a possible future change.

Instead the current fix focuses on blocking empty headers where they
are first inserted, hence in the H1/HPACK/QPACK decoders. One benefit
of the current solution (for H1) is that it allows "show errors" to
report a precise diagnostic when facing such invalid HTTP/1 requests,
with the exact location of the problem and the originating address:

  $ printf "GET / HTTP/1.1\r\nHost: localhost\r\n:empty header\r\n\r\n" | nc 0 8001
  HTTP/1.1 400 Bad request
  Content-length: 90
  Cache-Control: no-cache
  Connection: close
  Content-Type: text/html

  <html><body><h1>400 Bad request</h1>
  Your browser sent an invalid request.
  </body></html>

  $ socat /var/run/haproxy.stat <<< "show errors"
  Total events captured on [10/Feb/2023:16:29:37.530] : 1

  [10/Feb/2023:16:29:34.155] frontend decrypt (#2): invalid request
    backend <NONE> (#-1), server <NONE> (#-1), event #0, src 127.0.0.1:31092
    buffer starts at 0 (including 0 out), 16334 free,
    len 50, wraps at 16336, error at position 33
    H1 connection flags 0x00000000, H1 stream flags 0x00000810
    H1 msg state MSG_HDR_NAME(17), H1 msg flags 0x00001410
    H1 chunk len 0 bytes, H1 body len 0 bytes :

    00000  GET / HTTP/1.1\r\n
    00016  Host: localhost\r\n
    00033  :empty header\r\n
    00048  \r\n

I want to address sincere and warm thanks for their great work to the
team composed of the following security researchers who found the issue
together and reported it: Bahruz Jabiyev, Anthony Gavazzi, and Engin
Kirda from Northeastern University, Kaan Onarlioglu from Akamai
Technologies, Adi Peleg and Harvey Tuch from Google. And kudos to Amaury
Denoyelle from HAProxy Technologies for spotting that the HPACK and
QPACK decoders would let this pass despite the comment explicitly
saying otherwise.

This fix must be backported as far as 2.0. The QPACK changes can be
dropped before 2.6. In 2.0 there is also the equivalent code for legacy
mode, which doesn't suffer from the list truncation, but it would better
be fixed regardless.

Gbp-Pq: Name 2.0-2.5-BUG-CRITICAL-http-properly-reject-empty-http-header-.patch

BUG/MEDIUM: mux-h2: Refuse interim responses with end-stream flag set

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=038a7e8aeb1c5b90c18c55d2bcfb3aaa476bce89
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-0056
Bug: https://github.com/haproxy/haproxy/issues/1972

As state in RFC9113#8.1, HEADERS frame with the ES flag set that carries an
informational status code is malformed. However, there is no test on this
condition.

On 2.4 and higher, it is hard to predict consequences of this bug because
end of the message is only reported with a flag. But on 2.2 and lower, it
leads to a crash because there is an unexpected extra EOM block at the end
of an interim response.

Now, when a ES flag is detected on a HEADERS frame for an interim message, a
stream error is sent (RST_STREAM/PROTOCOL_ERROR).

This patch should solve the issue #1972. It should be backported as far as
2.0.

(cherry picked from commit 827a6299e6995c5c3ba620d8b7cbacdaef67f2c4)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ebfae006c6b5de1d1fe0cdd51847ec1e39d5cf59)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 84f5cba24f59b1c8339bb38323fcb01f434ba8e5)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit f5748a98c34bc889cae9386ca4f7073ab3f4c6b1)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 2c681c6f30fb90adab4701e287ff7a7db669b2e7)
[cf: ctx adjustment]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MEDIUM-mux-h2-Refuse-interim-responses-with-end-.patch

BUG/MAJOR: http/htx: prevent unbounded loop in http_manage_server_side_cookies

Origin: https://git.haproxy.org/?p=haproxy-2.2.git;a=commit;h=eb1bdcb7cf6e7bd1690f7dcc6d97de3d79b54cdc
Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2022-0711

Ensure calls to http_find_header() terminate. If a "Set-Cookie2"
header is found then the while(1) loop in
http_manage_server_side_cookies() will never terminate, resulting in
the watchdog firing and the process terminating via SIGABRT.

The while(1) loop becomes unbounded because an unmatched call to
http_find_header("Set-Cookie") will leave ctx->blk=NULL. Subsequent
calls to check for "Set-Cookie2" will now enumerate from the beginning
of all the blocks and will once again match on subsequent
passes (assuming a match first time around), hence the loop becoming
unbounded.

This issue was introduced with HTX and this fix should be backported
to all versions supporting HTX.

Many thanks to Grant Spence (gspence@redhat.com) for working through
this issue with me.

(cherry picked from commit bfb15ab34ead85f64cd6da0e9fb418c9cd14cee8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit d8ce72f63e115fa0952e6a58e81c3d15dfc0a509)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 86032c309b1f42177826deaa39f7c26903a074ca)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 3cd203d61609fd427234fdb4f793193980860348)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MAJOR-http-htx-prevent-unbounded-loop-in-http_ma.patch

BUG/MAJOR: htx: fix missing header name length check in htx_add_header/trailer

Shachar Menashe for JFrog Security reported that htx_add_header() and
htx_add_trailer() were missing a length check on the header name. While
this does not allow to overwrite any memory area, it results in bits of
the header name length to slip into the header value length and may
result in forging certain header names on the input. The sad thing here
is that a FIXME comment was present suggesting to add the required length
checks :-(

The injected headers are visible to the HTTP internals and to the config
rules, so haproxy will generally stay synchronized with the server. But
there is one exception which is the content-length header field, because
it is already deduplicated on the input, but before being indexed. As
such, injecting a content-length header after the deduplication stage
may be abused to present a different, shorter one on the other side and
help build a request smuggling attack, or even maybe a response splitting
attack.

As a mitigation measure, it is sufficient to verify that no more than
one such header is present in any message, which is normally the case
thanks to the duplicate checks:

http-request deny if { req.hdr_cnt(content-length) gt 1 }
http-response deny if { res.hdr_cnt(content-length) gt 1 }

This must be backported to all HTX-enabled versions, hence as far as 2.0.
In 2.3 and earlier, the functions are in src/htx.c instead.

Many thanks to Shachar for his work and his responsible report!

[wt: code is in src/htx.c in 2.3 and older]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 0001-2.0-2.3-BUG-MAJOR-htx-fix-missing-header-name-length-check-i.patch

[PATCH] BUG/MEDIUM: h2: match absolute-path not path-absolute for :path

RFC7540 states that :path follows RFC3986's path-absolute. However
that was a bug introduced in the spec between draft 04 and draft 05
of the spec, which implicitly causes paths starting with "//" to be
forbidden. HTTP/1 (and now HTTP core semantics) made it explicit
that the request-target in origin-form follows a purposely defined
absolute-path defined as 1*(/ segment) to explicitly allow "//".

http2bis now fixes this by relying on absolute-path so that "//"
becomes valid and matches other versions. Full discussion here:

https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0245.html

This issue appeared in haproxy with commit 4b8852c70 ("BUG/MAJOR: h2:
verify that :path starts with a '/' before concatenating it") when
making the checks on :path fully comply with the spec, and was backported
as far as 2.0, so this fix must be backported there as well to allow
"//" in H2 again.

(cherry picked from commit 46b7dff8f08cb6c5c3004d8874d6c5bc689a4c51)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 512cee88df5c40f1d3901a82cf6643fe9f74229e)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 65b9cf31a1975eb32e6696059c2bf9f0cfca2dff)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 0001-BUG-MEDIUM-h2-match-absolute-path-not-path-absolute-.patch

BUG/MEDIUM: h2: give :authority precedence over Host

The wording regarding Host vs :authority in RFC7540 is ambiguous as it
says that an intermediary must produce a host header from :authority if
Host is missing, but doesn't say anything regarding the possibility that
Host and :authority differ, which leaves Host with higher precedence
there. In addition it mentions that clients should use :authority
*instead* of Host, and that H1->H2 should use :authority only if the
original request was in authority form. This leaves some gray area in
the middle of the chain for fully valid H2 requests arboring a Host
header that are forwarded to the other side where it's possible to
drop the Host header and use the authority only after forwarding to a
second H2 layer, thus possibly seeing two different values of Host at
a different stage. There's no such issue when forwarding from H2 to H1
as the authority is dropped only only the Host is kept.

Note that the following request is sufficient to re-normalize such a
request:

http-request set-header host %[req.hdr(host)]

The new spec in progress (draft-ietf-httpbis-http2bis-03.html) addresses
this trouble by being a bit is stricter on these rules. It clarifies that
:authority must always be used instead of Host and that Host ought to be
ignored. This is much saner as it avoids to convey two distinct values
along the chain. This becomes the protocol-level equivalent of:

http-request set-uri %[url]

So this patch does exactly this, which we were initially a bit reluctant
to do initially by lack of visibiility about other implementation's
expectations. In addition it slightly simplifies the Host header field
creation by always placing it first in the list of headers instead of
last; this could speed up the look up a little bit.

This needs to be backported to 2.0. The legacy code there is a bit
different but not too much, the code can be simplified to simply
omit host during the copy and continue.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit 872e672e17d3fd22dd9d11d94fd98bb6fdd9779c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ab811714690aae3388626d38682b31914729244d)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 00bd4df20c74d22bb057bd11acfc7befe201a7b3)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0005-BUG-MEDIUM-h2-give-authority-precedence-over-Host.patch

BUG/MAJOR: h2: enforce checks on the method syntax before translating to HTX

The situation with message components in H2 is always troubling. They're
produced by the HPACK layer which contains a dictionary of well-known
hardcoded values, yet wants to remain binary transparent and protocol-
agnostic with HTTP just being one user, yet at the H2 layer we're
supposed to enforce some checks on some selected pseudo-headers that
come from internal constants... The :method pseudo-header is no exception
and is not tested when coming from the HPACK layer. This makes it possible
to pass random chars into methods, that can be serialized on another H2
connection (where they would not harm), or worse, on an H1 connection
where they can be used to transform the forwareded request. This is
similar to the request line injection described here:

   https://portswigger.net/research/http2

A workaround here is to reject malformed methods by placing this rule
in the frontend or backend, at least before leaving haproxy in H1:

   http-request reject if { method -m reg [^A-Z0-9] }

Alternately H2 may be globally disabled by commenting out the "alpn"
directive on "bind" lines, and by rejecting H2 streams creation by
adding the following statement to the global section:

   tune.h2.max-concurrent-streams 0

This patch adds a check for each character of the method to be part of
the ones permitted in a token, as mentioned in RFC7231#4.1. This should
be backported to versions 2.0 and above, maybe even 1.8. For older
versions not having HTX_FL_PARSING_ERROR, a "goto fail" works as well
as it results in a protocol error at the stream level. Non-HTX versions
were initially thought to be safe but must be carefully rechecked since
they transcode the request into H1 before processing it.

Thanks to Tim Düsterhus for reporting that one.

(cherry picked from commit b4be735a0a7c4a00bf3d774334763536774d7eea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 6b827f661374704e91322a82197bbfbfbf910f70)
[wt: adapted since no meth_sl in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit fbeb053d1a83faedbf3edbe04bde39bc7304cddd)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0004-BUG-MAJOR-h2-enforce-checks-on-the-method-syntax-bef.patch

BUG/MAJOR: h2: verify that :path starts with a '/' before concatenating it

Tim Düsterhus found that while the H2 path is checked for non-emptiness,
invalid chars and '*', a test is missing to verify that except for '*',
it always starts with exactly one '/'. During the reconstruction of the
full URI when passing to HTX, this allows to affect the apparent authority
by appending a port number or a suffix name.

This only affects H2-to-H2 communications, as H2-to-H1 do not use the
authority. Like for previous fix, the following rule installed in the
frontend or backend is sufficient to renormalize the internal URI:

http-request set-header host %[req.hdr(host)]

This needs to be backported to 2.2, since earlier versions do not rebuild
a full URI using the authority and will fail on the malformed path at the
HTTP layer.

(cherry picked from commit d3b22b75025246e81ff8d0c78837d4b89d7cf8f8)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2360306269ff65420cba7c847687a774b1025ab5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit c99c5cd3588a28978cd065abc74508fe81a93a40)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0003-BUG-MAJOR-h2-verify-that-path-starts-with-a-before-c.patch

BUG/MAJOR: h2: verify early that non-http/https schemes match the valid syntax

While we do explicitly check for strict character sets in the scheme,
this is only done when extracting URL components from an assembled one,
and we have special handling for "http" and "https" schemes directly in
the H2-to-HTX conversion. Sadly, this lets all other ones pass through
if they start exactly with "http://" or "https://", allowing the
reconstructed URI to start with a different looking authority if it was
part of the scheme.

It's interesting to note that in this case the valid authority is in
the Host hedaer and that the request will only be wrong if emitted over
H2 on the backend side, since H1 will not emit an absolute URI by
default and will drop the scheme. So in essence, this is a variant of
the scheme-based attack described below in that it only affects H2-H2
and not H2-H1 forwarding:

   https://portswigger.net/research/http2

As such, a simple workaround consists in just adding the following
rule in the frontend or backend, which will have for effect to
renormalize the authority in the request line according to the
concatenated version:

   http-request set-uri %[url]

This patch simply adds the missing syntax checks for non-http/https
schemes before the concatenation in the H2 code. An improvement may
consist in the future in splitting these ones apart in the start
line so that only the "url" sample fetch function requires to access
them together and that all other places continue to access them
separately. This will then allow the core code to perform such checks
itself.

The patch needs to be backported as far as 2.2. Before 2.2 the full
URI was not being reconstructed so the scheme and authority part were
always dropped from H2 requests to leave only origin requests. Note
for backporters: this depends on this previous patch:

  MINOR: http: add a new function http_validate_scheme() to validate a scheme

Many thanks to Tim Düsterhus for figuring that one and providing a
reproducer.

(cherry picked from commit d2b179db54846aee11356f033dfc490978147593)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2ac4f553cc1ea7a8a4ff28db18fa01f04b9d84ce)
[wt: no rfc8441 in 2.3]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit e618d9bf5f6b48bb45aceb8e7a886c43d62b3ed5)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0002-BUG-MAJOR-h2-verify-early-that-non-http-https-scheme.patch

MINOR: http: add a new function http_validate_scheme() to validate a scheme

While http_parse_scheme() extracts a scheme from a URI by extracting
exactly the valid characters and stopping on delimiters, this new
function performs the same on a fixed-size string.

(cherry picked from commit adfc08e717db600c3ac44ca8f3178d861699b67c)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 073e9c9c10897a05117f29cb9d3ebdbc13ff03b5)
[wt: context adj]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 0fb53c3c025fb158c51c515532f3f52bb2abcdea)
Signed-off-by: Willy Tarreau <w@1wt.eu>
Gbp-Pq: Name 2.2-0001-MINOR-http-add-a-new-function-http_validate_scheme-t.patch

[PATCH] BUG/MINOR: tcpcheck: Update .health threshold of agent inside an agent-check

If an agent-check is configured for a server, When the response is parsed,
the .health threshold of the agent must be updated on up/down/stopped/fail
command and not the threshold of the health-check. Otherwise, the
agent-check will compete with the health-check and may mark a DOWN server as
UP.

This patch should fix the issue #1176. It must be backported as far as 2.2.

(cherry picked from commit 24ec9434271345857b42cc5bd9c6b497ab01a7e4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 789bbdc88d7ffe8f520532efb18148ea52ede4ca)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Gbp-Pq: Name 0001-BUG-MINOR-tcpcheck-Update-.health-threshold-of-agent.patch

Add documentation field to the systemd unit

Forwarded: no
Last-Update: 2014-01-03

Gbp-Pq: Name haproxy.service-add-documentation.patch

Start after rsyslog.service

As HAProxy is running chrooted by default, we rely on an additional syslog
socket created by rsyslog inside the chroot for logging. As this socket cannot
trigger syslog activation, we explicitly order HAProxy after rsyslog.service.
Note that we are not using syslog.service here, since the additional socket is
rsyslog-specific.
Forwarded: no
Last-Update: 2017-12-01

Gbp-Pq: Name haproxy.service-start-after-syslog.patch

Use dpkg-buildflags to build halog

Forwarded: no
Last-Update: 2013-07-02

Gbp-Pq: Name 0002-Use-dpkg-buildflags-to-build-halog.patch

haproxy (2.2.9-2+deb11u6) bullseye-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * BUG/MAJOR: http: reject any empty content-length header value
    (CVE-2023-40225) (Closes: #1043502)
  * MINOR: ist: add new function ist_find_range() to find a character range
  * MINOR: ist: Add istend() function to return a pointer to the end of the
    string
  * MINOR: http: add new function http_path_has_forbidden_char()
  * MINOR: h2: pass accept-invalid-http-request down the request parser
  * BUG/MINOR: h1: do not accept '#' as part of the URI component
    (CVE-2023-45539)
  * BUG/MINOR: h2: reject more chars from the :path pseudo header
  * REGTESTS: http-rules: verify that we block '#' by default for
    normalize-uri
  * DOC: clarify the handling of URL fragments in requests

[dgit import unpatched haproxy 2.2.9-2+deb11u6]

Import haproxy_2.2.9-2+deb11u6.debian.tar.xz

[dgit import tarball haproxy 2.2.9-2+deb11u6 haproxy_2.2.9-2+deb11u6.debian.tar.xz]

Merge version 2.2.9-2+rpi1+deb11u4 and 2.2.9-2+deb11u5 to produce 2.2.9-2+rpi1+deb11u5

Merge haproxy (2.2.9-2+deb11u5) import into refs/heads/workingbranch