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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ