Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Mar 2014 13:23:36 +0100
From: Stefan B├╝hler <stbuehler@...httpd.net>
To: oss-security@...ts.openwall.com
Subject: lighttpd 1.4.34 SQL injection and path traversal CVE request

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@...hat.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

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.