Re: Securing suexec PHP against local attacks by the webserver user
| From: | Andrew | Date: | Mon, 09 Feb 2009 18:59:09 +0000 |
| Subject: | Re: Securing suexec PHP against local attacks by the webserver user | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-288013@lists.php.net to get a copy of this message | ||
Jochem Maas wrote:
Andrew schreef:Hi,....As an example of the attack... $ whoami www-dataisn't the whole point of suexec/PHP/FastCGI that the local user has no access to the www-data account ... suexec switches to the users account from the webserver account not the other way around. Yes, but only if everyone is using suexec/PHP/FastCGI... many shared hosting environments still allow access as the webserver account by also allowing mod_php or non-suexec CGI scripts (i.e. it is the customer's choice).
so the attack is moot unless there is a completely different security hole that allows the user to run stuff as www-data. Although this 'security hole' seems to be more the norm than the exception, and I have yet to find a shared hosting environment which doesn't either allow or force people to run code on the webserver as www-data. It therefore seems like there should be a way to protect against such attacks (ideally I'd like to be able to make my script which invokes php-cgi refuse to execute anything outside my public_html, whether called as CGI or FastCGI).Regards, Andrew
or am I being thick? ... could well be, socialists are renowned for their stupidity ... just look at the eminent socialist George W. Bush. so if I am being thick ... I would appreciate an explaination as to how the webuser account manages to run stuff in the context of the webserver account, if you have the inclination. PS - that last bit about socialism is off topic PPS - I don't think I'm a much of a socialist PPPS - I'm sure do I suffer from stupidity now and again PPPPS - but not as much as the guy whose world-view manages to put Dubya into a socialist pidgeonhole.$ cat >/tmp/myscript.php <?php passthru('whoami >/tmp/compromised.txt'); $ SCRIPT_FILENAME=/tmp/myscript.php PATH_INFO=/home/wwjargon/public_html/meter.php /usr/lib/apache2/suexec "~wwjargon" wwjargon php.fcgi X-Powered-By: PHP/5.2.6-2ubuntu4 Content-type: text/html $ cat /tmp/compromised.txt wwjargon I could make this attack a bit harder by changing the environment variables in php.fcgi so it would only work for FastCGI and not for normal CGI, but a more motivated attacker could just write a fake FastCGI server to attack my script. Setting PHP_DOCUMENT_ROOT in the environment and doc_root in php.ini didn't seem to stop the attack (although setting doc_root stops meter.php working, but not the attack), because PHP still happily serves up a document from /tmp/myscript.php, and --enable-force-cgi-redirect doesn't really have the potential to be of any help either because a local attacker could just set the same environment variables as the webserver to fake a redirect. I can't use the #!/usr/bin/php-cgi option because this is a FastCGI and not a CGI setup. What can I do to prevent this sort of local attack against my suexec/PHP/FastCGI environment (short of getting a VPS or installing my own patched PHP at least)? Thanks and Best Wishes, Andrew