lighttpd 1.4.34 SQL injection and path traversal

2014.03.14
Credit: Jann Horn
Risk: High
Local: No
Remote: Yes
CWE: N/A

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

Referencje:

http://seclists.org/oss-sec/2014/q1/564


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top