src/http-header-glue.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 [patch] [core] 101 upgrade fails if content-length incl (fixes #3063)

(thx daimh)

commit 903024d7 in lighttpd 1.4.57 fixed issue #3046 but in the process
broke HTTP/1.1 101 Switching Protocols which included Content-Length: 0
in the response headers.  Content-Length response header is permitted
by the RFCs, but not necessary with HTTP status 101 Switching Protocols.

x-ref:
  "websocket proxy fails if 101 Switching Protocols from backend includes Content-Length"
  https://redmine.lighttpd.net/issues/3063

src/connections.c | 22 21 + 1 - 0 !
src/mod_accesslog.c | 2 1 + 1 - 0 !
src/mod_auth.c | 6 3 + 3 - 0 !
src/reqpool.c | 1 1 + 0 - 0 !
src/request.h | 2 1 + 1 - 0 !
src/response.c | 4 2 + 2 - 0 !
6 files changed, 29 insertions(+), 8 deletions(-)

 [patch] [mod_auth] close http/2 connection after bad pass

mitigation slows down brute force password attacks

x-ref:
  "Possible feature: authentication brute force hardening"
  https://redmine.lighttpd.net/boards/3/topics/8885

src/mod_extforward.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] [mod_extforward] fix out-of-bounds (oob) write (fixes #3134)

(thx povcfe)

(edited: gstrauss)

There is a potential remote denial of service in lighttpd mod_extforward
under specific, non-default and uncommon 32-bit lighttpd mod_extforward
configurations.

Under specific, non-default and uncommon lighttpd mod_extforward
configurations, a remote attacker can trigger a 4-byte out-of-bounds
write of value '-1' to the stack. This is not believed to be exploitable
in any way beyond triggering a crash of the lighttpd server on systems
where the lighttpd server has been built 32-bit and with compiler flags
which enable a stack canary -- gcc/clang -fstack-protector-strong or
-fstack-protector-all, but bug not visible with only -fstack-protector.

With standard lighttpd builds using -O2 optimization on 64-bit x86_64,
this bug has not been observed to cause adverse behavior, even with
gcc/clang -fstack-protector-strong.

For the bug to be reachable, the user must be using a non-default
lighttpd configuration which enables mod_extforward and configures
mod_extforward to accept and parse the "Forwarded" header from a trusted
proxy. At this time, support for RFC7239 Forwarded is not common in CDN
providers or popular web server reverse proxies. It bears repeating that
for the user to desire to configure lighttpd mod_extforward to accept
"Forwarded", the user must also be using a trusted proxy (in front of
lighttpd) which understands and actively modifies the "Forwarded" header
sent to lighttpd.

lighttpd natively supports RFC7239 "Forwarded"
hiawatha natively supports RFC7239 "Forwarded"

nginx can be manually configured to add a "Forwarded" header
https://www.nginx.com/resources/wiki/start/topics/examples/forwarded/

A 64-bit build of lighttpd on x86_64 (not known to be affected by bug)
in front of another 32-bit lighttpd will detect and reject a malicious
"Forwarded" request header, thereby thwarting an attempt to trigger
this bug in an upstream 32-bit lighttpd.

src/mod_wstunnel.c | 5 4 + 1 - 0 !
1 file changed, 4 insertions(+), 1 deletion(-)

---

src/gw_backend.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---