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