In some circumstances, if the character on the heap prior to the
beginning of the request is '\r', then it would be overwritten with '\0'
With default compiler flags, this does not appear to occur in practice
and we therefore believe it to be a low-probability vulnerability.
(thx Antonio Morales)
This issue was discovered and reported by GSL team member @
<https://github.com/antonio-morales>antonio-morales
<https://github.com/antonio-morales> (Antonio Morales)
On some architectures, accept4() might result in EPERM depending
on Linux kernel and/or glibc support for accept4()
(thx alex-che)
x-ref:
"accept4 returns EPERM instead of ENOSYS on some platforms"
https://redmine.lighttpd.net/issues/2998
normalize %2b or %2B in query string to %2B (uppercase hex),
and not to '+'
(thx int-e)
x-ref:
"url-normalize-required expands %2B in query strings"
https://redmine.lighttpd.net/issues/2999
reject requests with both Transfer-Encoding and Content-Length
as recommended in RFC 7230 Section 3.3.3.
strict header parsing is enabled by default in lighttpd. However,
if explicitly disabled in lighttpd.conf, lighttpd will continue to
accept Transfer-Encoding and Content-Length in the same request,
and will ignore (and remove) Content-Length before passing to backend.
UNSAFE: server.http-parseopts = ( "header-strict" => "disable" )
This is NOT RECOMMENDED since doing so disables other protections
provided by lighttpd strict http header parsing.
RFC7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
3.3.3. Message Body Length
[...]
If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to
perform request smuggling (Section 9.5) or response splitting
(Section 9.4) and ought to be handled as an error. A sender MUST
remove the received Content-Length field prior to forwarding such
a message downstream.
x-ref:
stricter request header parsing
https://redmine.lighttpd.net/issues/2985
reject whitespace following request header field-name and before colon
Such whitespace is forbidden in RFC 7230 Section 3.2.4.
strict header parsing is enabled by default in lighttpd. However,
if explicitly disabled in lighttpd.conf, lighttpd will continue to
accept (and re-format) such field-names before passing to any backend.
UNSAFE: server.http-parseopts = ( "header-strict" => "disable" )
This is NOT RECOMMENDED since doing so disables other protections
provided by lighttpd strict http header parsing.
(thx fedormixalich)
x-ref:
stricter request header parsing
https://redmine.lighttpd.net/issues/2985
getaddrinfo() should return non-empty result list (res)
or else should return EAI_NONAME or some other error
(musl C library does not check for NULL argument to freeaddrinfo())
x-ref:
"Segmentation fault in mod_extforward with libmusl"
https://redmine.lighttpd.net/issues/2984
build postgres modules with $(PGSQL_CFLAGS) in Makefile.am
x-ref:
"pg_config is deprecated to build postgres client applications"
https://redmine.lighttpd.net/issues/2965
lighttpd requires a strict match between the request URI and the uri=
auth-param provided in the Authenticate header. lighttpd does not
attempt to determine if different URIs are semantically equivalent.
This commit removes a condition which permitted an Authenticate header
with a uri= containing a query-string to be used with the request-uri
which did not contain any query-string. The condition was likely added
in the original implementation which operated on lighttpd request.uri
instead of the correct request.orig_uri (original URI sent to lighttpd).
.
HTTP Digest Access Authentication
https://www.rfc-editor.org/rfc/rfc7616.txt
3.4.6. Various Considerations
The authenticating server MUST assure that the resource designated by
the "uri" parameter is the same as the resource specified in the
Request-Line; if they are not, the server SHOULD return a 400 Bad
Request error. (Since this may be a symptom of an attack, server
implementers may want to consider logging such errors.) The purpose
of duplicating information from the request URL in this field is to
deal with the possibility that an intermediate proxy may alter the
client's Request-Line. This altered (but presumably semantically
equivalent) request would not result in the same digest as that
calculated by the client.
x-ref:
"HTTP Digest Access Authentication"
https://www.rfc-editor.org/rfc/rfc7616.txt
"HTTP digest authentication not compatible with some clients"
https://redmine.lighttpd.net/issues/2974
https://www.rfc-editor.org/rfc/rfc7616.txt
3.3. The WWW-Authenticate Response Header Field
...
For historical reasons, a sender MUST only generate the quoted string
syntax values for the following parameters: realm, domain, nonce,
opaque, and qop.
For historical reasons, a sender MUST NOT generate the quoted string
syntax values for the following parameters: stale and algorithm.
employ volatile, which might matter with some compilers (or might not)
explicitly check that string lengths match
(or else might match string where last char of short string matches
repeated chars in longer string)
raw