Jann Horn reported a MySQL injection vulnerability in lighttpd  (a
lightweight webserver) version 1.4.34 (and earlier) through a
combination of two bugs:
* request_check_hostname is too lax: it allows any host names starting
with [ipv6-address] followed by anything but a colon, for example:
GET /etc/passwd HTTP/1.1
Host: [::1]' UNION SELECT '/
* mod_mysql_vhost doesn't perform any quoting; it just replaces ? in
the query string with the hostname.
mod_evhost and mod_simple_vhost are vulnerable in a limited way too; a
pattern: evhost.path-pattern = "/var/www/%0/" with a host
"/../../../" leads to document root of "/var/www//../../../", but
as "/var/www/" usually doesn't exists this fails (this might depend
on the operating system in use).
If there exist directories like "/var/www/[...]" for IPv6 addresses as
host names (or a user can create them) mod_evhost and mod_simple_vhost
are vulnerable too.
mod_status, mod_webdav and a global redirect handler use the host name
without escaping too; in this case the client just gets the broken data
back - the attacker doesn't gain anything here.
See our advisory for more details:
I requested a CVE on distros, but Kurt wasn't sure whether one or
multiple CVE ids should be assigned, and had some questions:
On Tue, 11 Mar 2014 14:58:53 -0600
Kurt Seifried <kseifried () redhat com> wrote:
[...] This appears
to be a messy CVE in the sense of intersecting vulnerabilities, but it
looks like we also have multiple vulns:
1) request_check_hostname filtering
2) mod_mysql_vhost doesn't perform any quoting - is there any way to
get data to it beyond the request_check_hostname? (I'm guessing no
known ways, but maybe in future one is found?)
It only uses the hostname as "input", and I can think of only 3 sources:
* Host: header
* request line: METHOD scheme://hostname/... HTTP/1.1
* config file
I think the first two get validated with request_check_hostname.
3) mod_evhost and mod_simple_vhost are potentially vuln as well - this
one seems less likely as you need the specific config pattern for the
directory, so request_check_hostname should be the only concern
Actually if you have "vhost" directories (or a user can create them)
like "[::]" (or real IPv6 addresses) they both are vulnerable to path
4) mod_status, mod_webdav and a global redirect handler use the host
name without escaping too; in this case the client just gets the
broken data back - the attacker doesn't gain anything here.
can #4 be used for anything like HTTP response splitting? XSS?
In this case the HTTP request would already be splitted afaics.
Imho the main bug is in request_check_hostname; it doesn't seem wrong
for a module to rely on valid hostnames. They don't read it from the
HTTP header list but use a special variable "uri.authority".
While we added hardening (quoting) in the mysql module, we did not
harden mod_evhost and mod_simple_vhost - they'll be relying on
Could you please assign one or multiple CVE ids?