chunkqueue_chunk_file_view()
reduces size of struct chunk
use mmap with mod_deflate libdeflate, if mmap available,
even when lighttpd not built with --enable-mmap
avoid using mmap on temp files in chunkqueue (c->file.is_temp)
since pread() with a reasonable block size is typically as fast
or faster than mmap on files read sequentially and used only once,
especially when writing results to limited-size socket buffers
(and lighttpd temp files are, in most cases, by default about 1 MB)
(Exception: sometimes mmap is used for convenience or to fulfill
a requirement, e.g. one-shot libdeflate in mod_deflate)
(There are many factors which influence speed of mmap versus pread,
so this should not be construed as generic usage advice.)
check lighty.result.content exists before setjmp() to avoid setjmp()
overhead if there is no content set via lua lighty.result.content
(response body could have been set via lua lighty.r.resp_body.* instead)
configure --with-libdeflate option to use libdeflate
(must also configure --enable-mmap for mod_deflate to use libdeflate
on input files larger than 64kB; libdeflate not used on files <= 64kB)
server.feature-flags += ( "http10.range" => "enable" )
The Range request header is HTTP/1.1, not HTTP/1.0.
Intermediate HTTP/1.0 proxies might mishandle or incorrectly cache
responses to HTTP/1.1 Range requests, so the default in lighttpd is
to ignore Range requests sent with HTTP/1.0.
This feature flag changes the default if an admin desires to support
dumb HTTP/1.0 clients that might (incorrectly) send Range requests
with HTTP/1.0. Those client really ought to grow HTTP/1.1 support:
add support to receive HTTP/1.1 Transfer-Encoding: chunked responses,
and then those client may safely send HTTP/1.1 Range requests
(and in many cases, also Connection: close).
(thx ryandesign)
There is no COPYFILE_CLONE_FORCE on OSX <10.12 so fall back to using
fcopyfile() to avoid race condition on source (if changed to dir) if
using copyfile() with flags equivalent to COPYFILE_CLONE_FORCE, but
without the 'force' flag.
x-ref:
"error: use of undeclared identifier 'COPYFILE_CLONE_FORCE'"
https://redmine.lighttpd.net/issues/3142
(thx ryandesign)
CCRandomGenerateBytes is a fallback and might be present alongside
crypto libraries which (previously) used the same variable name.
x-ref:
"error: redefinition of 'i'"
https://redmine.lighttpd.net/issues/3141
remove use of ssl->out_left in mbedtls 3.0.0
Discussed in https://github.com/ARMmbed/mbedtls/issues/5331,
the current implementations of mbedtls_net_send() and mbedtls_net_recv()
return MBEDTLS_ERR_SSL_WANT_WRITE only when there is a partial write
(though there is theoretical issue if writes are mixed with TLS alerts)
x-ref:
"issues migrating lighttpd mod_mbedtls to mbedtls 3.0.0"
https://github.com/ARMmbed/mbedtls/issues/5331
reconstruct SSL_CLIENT_S_DN in lighttpd due to limitations of
mbedtls_x509_dn_gets(). Adds support for non-ASCII UTF-8,
but loses support for multi-valued RDNs.
x-ref:
"Add access to mbedtls_x509_name::next_merged"
https://github.com/ARMmbed/mbedtls/issues/5431
unset flag which escapes chars with most-significant-bit set
for clean display of non-ASCII UTF-8 chars in cert subject
x-ref:
man X509_NAME_oneline
man ASN1_STRING_print_ex
optional bind spec override for tests/*.conf,
e.g. for use on platforms w/o socket activation
x-ref:
"TRACEME environment option in tests broken with LISTEN_PID"
https://redmine.lighttpd.net/issues/3137
allow LISTEN_PID to be ppid (parent pid) if TRACEME set in environment
(e.g. for strace, gdb on Linux; valgrind starts lighttpd as LISTEN_PID)
x-ref:
"TRACEME environment option in tests broken with LISTEN_PID"
https://redmine.lighttpd.net/issues/3137
(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.
The following servers currently do not natively support RFC7239 Forwarded:
nginx
apache2
caddy
node.js
haproxy
squid
varnish-cache
litespeed
Given the general dearth of support for RFC7239 Forwarded in popular
CDNs and web server reverse proxies, and given the prerequisites in
lighttpd mod_extforward needed to reach this bug, the number of lighttpd
servers vulnerable to this bug is estimated to be vanishingly small.
Large systems using reverse proxies are likely running 64-bit lighttpd,
which is not known to be adversely affected by this bug.
In the future, it is desirable for more servers to implement RFC7239
Forwarded. lighttpd developers would like to thank povcfe for reporting
this bug so that it can be fixed before more CDNs and web servers
implement RFC7239 Forwarded.
x-ref:
"mod_extforward plugin has out-of-bounds (OOB) write of 4-byte -1"
https://redmine.lighttpd.net/issues/3134
(not yet written or published)
CVE-2022-22707
remove (minor) convenience func; easy to replace
Like buffer_init_string(), buffer_init_buffer() was used in only a few
places at startup or in cold funcs, so better off removed from buffer.c
povcfe