Re: [ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev

[Willy Tarreau]

On Tue, Sep 07, 2021 at 09:39:41PM +0200, Vincent Bernat wrote:
>  ?  7 September 2021 17:27 +02, Willy Tarreau:
> 
> > I'd like to thank the usual distro maintainers for having accepted to
> > produce yet another version of their packages in a short time. Hopefully
> > now we can all get back to development!
> 
> For Debian/Ubuntu, the fixed versions are:
> 
> 2.4.3-2
> 2.4.3-2~bpo10+1
> 2.4.3-2~bpo11+1
> 2.4.3-2ppa2~bionic
> 2.4.3-2ppa1~focal
> 
> 2.3.13-2
> 2.3.13-2~bpo10+1
> 2.3.13-2ppa1~bionic
> 2.3.13-2ppa1~focal
> 
> 2.2.16-3
> 2.2.16-3~bpo9+1
> 2.2.16-3~bpo10+1
> 2.2.16-3ppa1~bionic
> 2.2.16-3ppa1~focal
> 2.2.9-2+deb11u2 (to be released pretty soon)
> 2.2.9-2+deb11u2~bpo10+1 (not released yet)
> 2.2.9-1ubuntu0.2 (not 100% sure as it is not released yet)
> 
> 2.0.24-1
> 2.0.24-1~bpo9+1
> 2.0.24-1~bpo10+1
> 2.0.24-1ppa1~xenial
> 2.0.24-1ppa1~bionic
> 2.0.24-1ppa1~focal
> 2.0.13-2ubuntu0.3 (not 100% sure as it is not released yet)

Thank you Vincent!
Willy

Re: [ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev

[Vincent Bernat]

 ❦  7 September 2021 17:27 +02, Willy Tarreau:

> I'd like to thank the usual distro maintainers for having accepted to
> produce yet another version of their packages in a short time. Hopefully
> now we can all get back to development!

For Debian/Ubuntu, the fixed versions are:

2.4.3-2
2.4.3-2~bpo10+1
2.4.3-2~bpo11+1
2.4.3-2ppa2~bionic
2.4.3-2ppa1~focal

2.3.13-2
2.3.13-2~bpo10+1
2.3.13-2ppa1~bionic
2.3.13-2ppa1~focal

2.2.16-3
2.2.16-3~bpo9+1
2.2.16-3~bpo10+1
2.2.16-3ppa1~bionic
2.2.16-3ppa1~focal
2.2.9-2+deb11u2 (to be released pretty soon)
2.2.9-2+deb11u2~bpo10+1 (not released yet)
2.2.9-1ubuntu0.2 (not 100% sure as it is not released yet)

2.0.24-1
2.0.24-1~bpo9+1
2.0.24-1~bpo10+1
2.0.24-1ppa1~xenial
2.0.24-1ppa1~bionic
2.0.24-1ppa1~focal
2.0.13-2ubuntu0.3 (not 100% sure as it is not released yet)
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)

Re: BoringSSL commit dddb60e breaks compilation of HAProxy

[Илья Шипицин]

yep :)

CI: Github Actions: temporarily disable BoringSSL builds ·
haproxy/haproxy@30ee296


I had a look, I found the same as you (no easy fix).

let us open github issue for tracking this.


вт, 7 сент. 2021 г. в 22:58, Zakharychev, Bob :

> BoringSSL commit dddb60e, "Make most of crypto/x509 opaque.", breaks
> compilation of HAProxy with the following errors (log from compiling
> HAProxy 2.4.4 with BoringSSL master branch commit a03c34c, but I suppose
> all other versions are equally affected):
>
>
> …
>
>   CC  src/ssl_sample.o
>
> In file included from include/haproxy/listener-t.h:37,
>
>  from include/haproxy/server-t.h:36,
>
>  from include/haproxy/lb_map-t.h:26,
>
>  from include/haproxy/backend-t.h:30,
>
>  from include/haproxy/proxy-t.h:35,
>
>  from include/haproxy/applet-t.h:31,
>
>  from include/haproxy/obj_type.h:26,
>
>  from src/ssl_sample.c:27:
>
> include/haproxy/openssl-compat.h: In function ‘X509_OBJECT_get0_X509_CRL’:
>
> include/haproxy/openssl-compat.h:182:23: error: dereferencing pointer to
> incomplete type ‘X509_OBJECT’ {aka ‘const struct x509_object_st’}
>
>  if (a == NULL || a->type != X509_LU_CRL) {
>
>^~
>
> src/ssl_sample.c: In function ‘smp_fetch_ssl_x_key_alg’:
>
> include/haproxy/openssl-compat.h:122:37: error: dereferencing pointer to
> incomplete type ‘X509’ {aka ‘struct x509_st’}
>
> #define X509_get_X509_PUBKEY(x) ((x)->cert_info->key)
>
>  ^~
>
> src/ssl_sample.c:716:55: note: in expansion of macro ‘X509_get_X509_PUBKEY’
>
>   X509_PUBKEY_get0_param(, NULL, NULL, NULL,
> X509_get_X509_PUBKEY(crt));
>
>^~~~
>
> make: *** [Makefile:945: src/ssl_sample.o] Error 1
>
>
>
> Indeed, BoringSSL commit dddb60e “unexported” these structs “aligning with
> OpenSSL” and directs to “Use the accessor APIs instead”. I couldn't figure
> out an easy fix to this - simply removing the two macros conditional on
> OPENSSL_IS_BORINGSSL in affected places doesn't fully help because while
> X509_get_X509_PUBKEY() accessor is now defined, X509_OBJECT_get0_X509_CRL()
> is still missing in BoringSSL. Therefore I defer the fix to HAProxy SSL
> experts - maybe it's actually BoringSSL that needs to be fixed by adding
> the missing accessor, or maybe the single loop in ssl_set_cert_crl_file()
> over all X509 store objects needs to be broken into two loops: one over
> certs returned by X509_STORE_get1_certs() and another over CRLs returned by
> X509_STORE_get1_crls().
>
> Thanks in advance for taking a stab at this,
>   Bob
>
>
>
>
>

Re: Server current weight

[Prytoegrian]

Hi Willy,

thanks for your message. I studied the code base responsible of CLI response, 
it's indeed tricky to change.

In your opinion, what's the next step ? Is creating a new bug issue relevant ? 


Prytoegrian


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

Le jeudi 2 septembre 2021 à 14:49, Willy Tarreau  a écrit :

> Hello,
> 

> On Sun, Aug 29, 2021 at 11:28:43AM +, Prytoegrian wrote:
> 

> > I think I found a bug in Haproxy but I first want to be sure it's a real 
> > one.
> > 

> > It might just be a semantic misunderstanding of mine.
> > 

> > I described a backend with two servers, one of them with "slowstart" option.
> > 

> > When I set it in maintenance then ready again, CLI `get weight` doesn't show
> > 

> > current weight, like the stat page could displays, but the user defined one.
> > 

> > The documentation in the associated function states
> > 

> > // cli_parse_get_weight
> > /* return server's effective weight at the moment */
> > 

> > 

> > effective weight having a precise meaning in haproxy.
> 

> The CLI's documentation (management.txt) is correct and says:
> 

> get weight /
> 

> Report the current weight and the initial weight of server  in
> 

> backend  or an error if either doesn't exist. The initial weight is
> 

> the one that appears in the configuration file. Both are normally equal
> 

> unless the current weight has been changed. Both the backend and the server
> 

> may be specified either by their name or by their numeric ID, prefixed with a
> 

> sharp ('#').
> 

> We wanted the "get" commands to perform the opposite of "set" so that
> 

> scripts can use "get" on a value, recompute it and send the new one
> 

> with "set".
> 

> Regarding servers' weights, there are 3 values:
> 

> -   the initial one (that would rather be called the configured one),
> 

> it is the weight that was initially configured with the server and
> 

> that is used for percentages (e.g. if you change your weight to 50%,
> 

> it's 50% of this one).
> -   the user weight, which is the currently configured one, as the
> 

> result of a "set weight" command, either using an absolute value
> 

> or a relative one. It used to be called the effective one a long
> 

> time ago (which explains the comment you found in the source file
> 

> above).
> -   the effective weight, which is the one applied to the server at the
> 

> moment you're watching, and which is the user weight modulated by
> 

> the slowstart ratio. This one is reported in the stats so that it's
> 

> visible why a server only takes a small amount of charge (some users
> 

> used to have very long slowstart periods and were confused without
> 

> it).
> 

> Lesson learned: "never call something effective as you might still find
> 

> a new way to post-process it down the chain later"!
> 

> We could imagine to add the effective one to the "get weight" output
> 

> as well, but then we'd need to be extremely careful not to break
> 

> possibly existing scripts that rely on dumping $3 or last field etc
> 

> so that's not as easy as it seems.
> 

> > Did I understand the expected behavior right ?
> 

> Both yes and no :-) There was some confusion induced by the feature
> 

> having been extended over time to include a third value.
> 

> Hoping this helps,
> 

> Willy

publickey - prytoegrian@protonmail.com - 0xD78075EC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

BoringSSL commit dddb60e breaks compilation of HAProxy

[Zakharychev, Bob]

BoringSSL commit dddb60e, "Make most of crypto/x509 opaque.", breaks 
compilation of HAProxy with the following errors (log from compiling HAProxy 
2.4.4 with BoringSSL master branch commit a03c34c, but I suppose all other 
versions are equally affected):

...
  CC  src/ssl_sample.o
In file included from include/haproxy/listener-t.h:37,
 from include/haproxy/server-t.h:36,
 from include/haproxy/lb_map-t.h:26,
 from include/haproxy/backend-t.h:30,
 from include/haproxy/proxy-t.h:35,
 from include/haproxy/applet-t.h:31,
 from include/haproxy/obj_type.h:26,
 from src/ssl_sample.c:27:
include/haproxy/openssl-compat.h: In function 'X509_OBJECT_get0_X509_CRL':
include/haproxy/openssl-compat.h:182:23: error: dereferencing pointer to 
incomplete type 'X509_OBJECT' {aka 'const struct x509_object_st'}
 if (a == NULL || a->type != X509_LU_CRL) {
   ^~
src/ssl_sample.c: In function 'smp_fetch_ssl_x_key_alg':
include/haproxy/openssl-compat.h:122:37: error: dereferencing pointer to 
incomplete type 'X509' {aka 'struct x509_st'}
#define X509_get_X509_PUBKEY(x) ((x)->cert_info->key)
 ^~
src/ssl_sample.c:716:55: note: in expansion of macro 'X509_get_X509_PUBKEY'
  X509_PUBKEY_get0_param(, NULL, NULL, NULL, 
X509_get_X509_PUBKEY(crt));
   ^~~~
make: *** [Makefile:945: src/ssl_sample.o] Error 1

Indeed, BoringSSL commit dddb60e "unexported" these structs "aligning with 
OpenSSL" and directs to "Use the accessor APIs instead". I couldn't figure out 
an easy fix to this - simply removing the two macros conditional on 
OPENSSL_IS_BORINGSSL in affected places doesn't fully help because while 
X509_get_X509_PUBKEY() accessor is now defined, X509_OBJECT_get0_X509_CRL() is 
still missing in BoringSSL. Therefore I defer the fix to HAProxy SSL experts - 
maybe it's actually BoringSSL that needs to be fixed by adding the missing 
accessor, or maybe the single loop in ssl_set_cert_crl_file() over all X509 
store objects needs to be broken into two loops: one over certs returned by 
X509_STORE_get1_certs() and another over CRLs returned by 
X509_STORE_get1_crls().

Thanks in advance for taking a stab at this,
  Bob

[ANNOUNCE] haproxy-2.0.25

[Willy Tarreau]

Hi,

HAProxy 2.0.25 was released on 2021/09/07. It added 16 new commits
after version 2.0.24.

This version essentially aims at fixing the HTX header encoding issue
mentioned in a previous message, and that may lead to a request smuggling
attack. All users must update.

Another important fix for some users is the relaxed double-slash rule in
the H2 parser, because the previous H2 fixes would (rightfully) block
requests starting by "//" due to a bug in the H2 spec itself! The nice
thing is that it allowed to spot and fix a bug in the spec :-)

A recent fix for "option abortonclose" has resulted in an issue for a
user who sometimes sees some streams looping. The fix was reverted for
now as the situation is worse than before, and the issue is still under
investigation.

A failed backport of a recent fix in 2.2.16 for early connection failures
was better addressed this time. It would manifest itself by high CPU usage
on certain threads, with the poller reporting the same FDs all the time.

The remaining fixes are less important:
  - use thread-safe versions of localtime()/gmtime() in the ltime/utime
converters; previously it was theoretically possible to occasionally
retrieve a bad date under high thread contention

  - fix for incorrect output size check in the base64dec/base64urldec
converters that could write up to 2 extra bytes, but normally they're
always used with outputs having sufficient room so I can't figure a
case where it could have represented a practical problem.

  - tune.bufsize is now checked for being smaller than 256 MB in HTX mode
(that's the hard limit).

  - Lua's initialization of sample converters now uses strlcpy2() and not
strncpy(), as this last one used to fill the entire buffer with zeroes,
resulting in a measurable startup time when using large buffers (a
second or so with 1 MB buffers).

  - the sc-set-gpt* action parser was off by one argument and was ignoring
one word before the "if" condition, forcing to write garbage there (or
a second "if").

Please find the usual URLs below :
   Site index   : http://www.haproxy.org/
   Discourse: http://discourse.haproxy.org/
   Slack channel: https://slack.haproxy.org/
   Issue tracker: https://github.com/haproxy/haproxy/issues
   Wiki : https://github.com/haproxy/wiki/wiki
   Sources  : http://www.haproxy.org/download/2.0/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.0.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.0.git
   Changelog: http://www.haproxy.org/download/2.0/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Christopher Faulet (2):
  Revert "BUG/MINOR: stream-int: Don't block reads in si_update_rx() if chn 
may receive"
  MINOR: action: Use a generic function to check validity of an action rule 
list

Dragan Dosen (1):
  BUG/MEDIUM: base64: check output boundaries within base64{dec,urldec}

Tim Duesterhus (3):
  BUG/MINOR threads: Use get_(local|gm)time instead of (local|gm)time
  BUG/MINOR: tools: Fix loop condition in dump_text()
  CLEANUP: Add missing include guard to signal.h

Willy Tarreau (10):
  BUG/MEDIUM: sock: really fix detection of early connection failures in 
for 2.3-
  REGTESTS: abortonclose: after retries, 503 is expected, not close
  MINOR: compiler: implement an ONLY_ONCE() macro
  BUG/MINOR: lua: use strlcpy2() not strncpy() to copy sample keywords
  BUG/MINOR: ebtree: remove dependency on incorrect macro for bits per long
  DOC: configuration: remove wrong tcp-request examples in tcp-response
  BUG/MINOR: config: reject configs using HTTP with bufsize >= 256 MB
  CLEANUP: htx: remove comments about "must be < 256 MB"
  BUG/MAJOR: htx: fix missing header name length check in 
htx_add_header/trailer
  REGTESTS: mark http_abortonclose as broken

---

[ANNOUNCE] haproxy-2.2.17

[Willy Tarreau]

Hi,

HAProxy 2.2.17 was released on 2021/09/07. It added 18 new commits
after version 2.2.16.

This version essentially aims at fixing the HTX header encoding issue
mentioned in a previous message, and that may lead to a request smuggling
attack. All users must update.

Another important fix for some users is the relaxed double-slash rule in
the H2 parser, because the previous H2 fixes would (rightfully) block
requests starting by "//" due to a bug in the H2 spec itself! The nice
thing is that it allowed to spot and fix a bug in the spec :-)

A recent fix for "option abortonclose" has resulted in an issue for a
user who sometimes sees some streams looping. The fix was reverted for
now as the situation is worse than before, and the issue is still under
investigation.

A failed backport of a recent fix in 2.2.16 for early connection failures
was better addressed this time. It would manifest itself by high CPU usage
on certain threads, with the poller reporting the same FDs all the time.

The remaining fixes are less important:
  - use thread-safe versions of localtime()/gmtime() in the ltime/utime
converters; previously it was theoretically possible to occasionally
retrieve a bad date under high thread contention

  - fix for incorrect output size check in the base64dec/base64urldec
converters that could write up to 2 extra bytes, but normally they're
always used with outputs having sufficient room so I can't figure a
case where it could have represented a practical problem.

  - tune.bufsize is now checked for being smaller than 256 MB in HTX mode
(that's the hard limit).

  - Lua's initialization of sample converters now uses strlcpy2() and not
strncpy(), as this last one used to fill the entire buffer with zeroes,
resulting in a measurable startup time when using large buffers (a
second or so with 1 MB buffers).

  - the sc-set-gpt* action parser was off by one argument and was ignoring
one word before the "if" condition, forcing to write garbage there (or
a second "if").

Please find the usual URLs below :
   Site index   : http://www.haproxy.org/
   Discourse: http://discourse.haproxy.org/
   Slack channel: https://slack.haproxy.org/
   Issue tracker: https://github.com/haproxy/haproxy/issues
   Wiki : https://github.com/haproxy/wiki/wiki
   Sources  : http://www.haproxy.org/download/2.2/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.2.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.2.git
   Changelog: http://www.haproxy.org/download/2.2/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Christopher Faulet (2):
  Revert "BUG/MINOR: stream-int: Don't block reads in si_update_rx() if chn 
may receive"
  MINOR: action: Use a generic function to check validity of an action rule 
list

Dragan Dosen (1):
  BUG/MEDIUM: base64: check output boundaries within base64{dec,urldec}

Tim Duesterhus (3):
  BUG/MINOR threads: Use get_(local|gm)time instead of (local|gm)time
  BUG/MINOR: tools: Fix loop condition in dump_text()
  CLEANUP: Add missing include guard to signal.h

Willy Tarreau (12):
  BUG/MEDIUM: h2: match absolute-path not path-absolute for :path
  BUG/MEDIUM: sock: really fix detection of early connection failures in 
for 2.3-
  REGTESTS: abortonclose: after retries, 503 is expected, not close
  BUG/MINOR: stick-table: fix the sc-set-gpt* parser when using expressions
  MINOR: compiler: implement an ONLY_ONCE() macro
  BUG/MINOR: lua: use strlcpy2() not strncpy() to copy sample keywords
  BUG/MINOR: ebtree: remove dependency on incorrect macro for bits per long
  DOC: configuration: remove wrong tcp-request examples in tcp-response
  BUG/MINOR: config: reject configs using HTTP with bufsize >= 256 MB
  CLEANUP: htx: remove comments about "must be < 256 MB"
  BUG/MAJOR: htx: fix missing header name length check in 
htx_add_header/trailer
  REGTESTS: mark http_abortonclose as broken

---

[ANNOUNCE] haproxy-2.3.14

[Willy Tarreau]

Hi,

HAProxy 2.3.14 was released on 2021/09/07. It added 19 new commits
after version 2.3.13.

This version essentially aims at fixing the HTX header encoding issue
mentioned in a previous message, and that may lead to a request smuggling
attack. All users must update.

Another important fix for some users is the relaxed double-slash rule in
the H2 parser, because the previous H2 fixes would (rightfully) block
requests starting by "//" due to a bug in the H2 spec itself! The nice
thing is that it allowed to spot and fix a bug in the spec :-)

A recent fix for "option abortonclose" has resulted in an issue for a
user who sometimes sees some streams looping. The fix was reverted for
now as the situation is worse than before, and the issue is still under
investigation.

A failed backport of a recent fix in 2.3.13 for early connection failures
was better addressed this time. It would manifest itself by high CPU usage
on certain threads, with the poller reporting the same FDs all the time.

The remaining fixes are less important:
  - use thread-safe versions of localtime()/gmtime() in the ltime/utime
converters; previously it was theoretically possible to occasionally
retrieve a bad date under high thread contention

  - fix for incorrect output size check in the base64dec/base64urldec
converters that could write up to 2 extra bytes, but normally they're
always used with outputs having sufficient room so I can't figure a
case where it could have represented a practical problem.

  - tune.bufsize is now checked for being smaller than 256 MB in HTX mode
(that's the hard limit).

  - Lua's initialization of sample converters now uses strlcpy2() and not
strncpy(), as this last one used to fill the entire buffer with zeroes,
resulting in a measurable startup time when using large buffers (a
second or so with 1 MB buffers).

  - the sc-set-gpt* action parser was off by one argument and was ignoring
one word before the "if" condition, forcing to write garbage there (or
a second "if").

Please find the usual URLs below :
   Site index   : http://www.haproxy.org/
   Discourse: http://discourse.haproxy.org/
   Slack channel: https://slack.haproxy.org/
   Issue tracker: https://github.com/haproxy/haproxy/issues
   Wiki : https://github.com/haproxy/wiki/wiki
   Sources  : http://www.haproxy.org/download/2.3/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.3.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.3.git
   Changelog: http://www.haproxy.org/download/2.3/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Christopher Faulet (2):
  Revert "BUG/MINOR: stream-int: Don't block reads in si_update_rx() if chn 
may receive"
  MINOR: action: Use a generic function to check validity of an action rule 
list

Dragan Dosen (1):
  BUG/MEDIUM: base64: check output boundaries within base64{dec,urldec}

Tim Duesterhus (3):
  BUG/MINOR threads: Use get_(local|gm)time instead of (local|gm)time
  BUG/MINOR: tools: Fix loop condition in dump_text()
  CLEANUP: Add missing include guard to signal.h

Willy Tarreau (13):
  BUG/MEDIUM: h2: match absolute-path not path-absolute for :path
  BUG/MEDIUM: sock: really fix detection of early connection failures in 
for 2.3-
  REGTESTS: abortonclose: after retries, 503 is expected, not close
  BUG/MINOR: stick-table: fix the sc-set-gpt* parser when using expressions
  MINOR: compiler: implement an ONLY_ONCE() macro
  BUG/MINOR: lua: use strlcpy2() not strncpy() to copy sample keywords
  BUG/MINOR: ebtree: remove dependency on incorrect macro for bits per long
  BUG/MINOR: vars: fix set-var/unset-var exclusivity in the keyword parser
  DOC: configuration: remove wrong tcp-request examples in tcp-response
  BUG/MINOR: config: reject configs using HTTP with bufsize >= 256 MB
  CLEANUP: htx: remove comments about "must be < 256 MB"
  BUG/MAJOR: htx: fix missing header name length check in 
htx_add_header/trailer
  REGTESTS: mark http_abortonclose as broken

---

[ANNOUNCE] haproxy-2.4.4

[Willy Tarreau]

Hi,

HAProxy 2.4.4 was released on 2021/09/07. It added 21 new commits
after version 2.4.3.

This version essentially aims at fixing the HTX header encoding issue
mentioned in a previous message, and that may lead to a request smuggling
attack. All users must update.

Another important fix for some users is the relaxed double-slash rule in
the H2 parser, because the previous H2 fixes would (rightfully) block
requests starting by "//" due to a bug in the H2 spec itself! The nice
thing is that it allowed to spot and fix a bug in the spec :-)

A recent fix for "option abortonclose" has resulted in an issue for a
user who sometimes sees some streams looping. The fix was reverted for
now as the situation is worse than before, and the issue is still under
investigation.

The remaining fixes are less important:
  - use thread-safe versions of localtime()/gmtime() in the ltime/utime
converters; previously it was theoretically possible to occasionally
retrieve a bad date under high thread contention

  - fix for incorrect output size check in the base64dec/base64urldec
converters that could write up to 2 extra bytes, but normally they're
always used with outputs having sufficient room so I can't figure a
case where it could have represented a practical problem.

  - tune.bufsize is now checked for being smaller than 256 MB in HTX mode
(that's the hard limit).

  - Lua's initialization of sample converters now uses strlcpy2() and not
strncpy(), as this last one used to fill the entire buffer with zeroes,
resulting in a measurable startup time when using large buffers (a
second or so with 1 MB buffers).

  - the sc-set-gpt* action parser was off by one argument and was ignoring
one word before the "if" condition, forcing to write garbage there (or
a second "if").

  - the idle time computation would overflow for sleep times greater than
42 seconds and could mistakenly report low idle values under low load.
The idle value reported in the stats will now also reflect the process
wide value and not the randomly picked thread's value.

Please find the usual URLs below :
   Site index   : http://www.haproxy.org/
   Discourse: http://discourse.haproxy.org/
   Slack channel: https://slack.haproxy.org/
   Issue tracker: https://github.com/haproxy/haproxy/issues
   Wiki : https://github.com/haproxy/wiki/wiki
   Sources  : http://www.haproxy.org/download/2.4/src/
   Git repository   : http://git.haproxy.org/git/haproxy-2.4.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy-2.4.git
   Changelog: http://www.haproxy.org/download/2.4/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Christopher Faulet (1):
  Revert "BUG/MINOR: stream-int: Don't block reads in si_update_rx() if chn 
may receive"

Dragan Dosen (2):
  BUG/MEDIUM: base64: check output boundaries within base64{dec,urldec}
  BUG/MINOR: base64: base64urldec() ignores padding in output size check

Tim Duesterhus (3):
  BUG/MINOR threads: Use get_(local|gm)time instead of (local|gm)time
  BUG/MINOR: tools: Fix loop condition in dump_text()
  CLEANUP: Add missing include guard to signal.h

Willy Tarreau (15):
  BUG/MEDIUM: h2: match absolute-path not path-absolute for :path
  REGTESTS: http_upgrade: fix incorrect expectation on TCP->H1->H2
  REGTESTS: abortonclose: after retries, 503 is expected, not close
  MINOR: hlua: take the global Lua lock inside a global function
  BUG/MINOR: stick-table: fix the sc-set-gpt* parser when using expressions
  MINOR: compiler: implement an ONLY_ONCE() macro
  BUG/MINOR: lua: use strlcpy2() not strncpy() to copy sample keywords
  BUG/MINOR: time: fix idle time computation for long sleeps
  MINOR: time: add report_idle() to report process-wide idle time
  BUG/MINOR: ebtree: remove dependency on incorrect macro for bits per long
  BUG/MINOR: vars: fix set-var/unset-var exclusivity in the keyword parser
  DOC: configuration: remove wrong tcp-request examples in tcp-response
  BUG/MINOR: config: reject configs using HTTP with bufsize >= 256 MB
  CLEANUP: htx: remove comments about "must be < 256 MB"
  BUG/MAJOR: htx: fix missing header name length check in 
htx_add_header/trailer

---

[ANNOUNCE] HTX vulnerability from 2.0 to 2.5-dev

[Willy Tarreau]

Hi everyone,   

Right after the previous announce of HTTP/2 vulnerabilities, a group
of security researchers from JFrog Security have been looking for the
possibility of remaining issues around the same topic. While there was
nothing directly exploitable, Ori Hollander found a bug in the HTTP
header name length encoding in the HTX representation by which the most
significant bit of the name's length can slip into the value's least
significant bit, and figured he could craft a valid request that could
inject a dummy content-length on input that would be produced on output
in addition to the other one, resulting in the possibility of a blind
request smuggling attack ("blind" because the response never gets back
to the attacker). Quite honestly they've done an excellent job at
spotting this one because it's not every day that you manage to turn
a single-bit overflow into an extra request, and figuring this required
to dig deeply into the layers! It's likely that they'll publish something
shortly about their finding.

CVE-2021-40346 was assigned to this issue, which affects versions 2.0
and above. I'm going to emit new maintenance releases for 2.0, 2.2, 2.3
and 2.4 (2.5 still being in development, it will be released a bit later).

A possible workaround for those who cannot upgrade is to block requests
and responses featuring more than one content-length header after the
overflow occured; these ones are always invalid because they're always
resolved during the parsing phase, hence this condition never reaches
the HTTP layer:

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

I'd like to thank the usual distro maintainers for having accepted to
produce yet another version of their packages in a short time. Hopefully
now we can all get back to development!

Thanks,
Willy