Home page logo
/

oss-sec logo oss-sec mailing list archives

lighttpd 1.4.34 SQL injection and path traversal CVE request
From: Stefan Bühler <stbuehler () lighttpd net>
Date: Wed, 12 Mar 2014 13:23:36 +0100

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]