Bug #2523
closedPHP vulnerability
Description
Hi,
I've recently seen an apache/php-cgi vulnerabilty.
http://www.exploit-db.com/exploits/29290/
Is lighttpd vulnerable to it?
Thanks
Updated by stbuehler over 10 years ago
- Category deleted (
mod_fastcgi) - Status changed from Need Feedback to Invalid
- Target version deleted (
1.4.x)
No, not vulnerable afaics. (It may theoretically be possible to configure similar "ScriptAlias"es as apache uses, like a url.rewrite = ("*.php" => "/cgi-bin/php5-cgi/$0")
+ alias.url = ("/cgi-bin/php5-cgi" => /usr/bin/php5-cgi")
, in which case i'd need a closer look at what the exploit is doing... but lighttpd is (imho) superior in its config style, as you usually just do cgi.assign = (".php" => "/usr/bin/php5-cgi")
or fastcgi.server = ( ".php" => (...))
- no unnecessary aliases involved.)
Updated by stbuehler over 10 years ago
Afaics the exploit uses an url like this (escaping all the stuff ofc):
/cgi-bin/php5-cgi?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -n
Now either apache appends this query string to the exec call as argument(s), in which case apache is to blame, and lighttpd is not vulnerable (in mod_cgi we only call exec with a configured handler and the filename as the only parameter, or directly the filename if it is an executable itself and an empty handler is configured. no query string ever gets used as argument).
Or php reads commandline options from the query string (but I think this is unlikely), in which case only php is to be blamed.
Also available in: Atom