lighttpd 1.4.34 SQL injection and path traversal CVE request

[Stefan Bühler <stbuehler () lighttpd net>]

Hi,

Jann Horn reported a MySQL injection vulnerability in lighttpd [1] (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:
http://download.lighttpd.net/lighttpd/security/lighttpd_sa_2014_01.txt

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  

Yes.

> 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
> right?  

Actually if you have "vhost" directories (or a user can create them)
like "[::]" (or real IPv6 addresses) they both are vulnerable to path
traversal.

> 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
request_check_hostname.

Could you please assign one or multiple CVE ids?

Regards,
Stefan