Andrew schreef: > Jochem Maas wrote: >> Andrew schreef: >> >>> Hi, >>> >>> >> >> .... >> >> >>> As an example of the attack... >>> $ whoami >>> www-data >>> >> >> isn'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). are you worried that someone else's customer will screw with your customers scripts/data? or whether your customer will screw with it? in the former case, get a VPS and control the environment (all round nice guy Dan Brown comes recommended round these parts ... he live's in a bash shell and never sleeps) in the later ... get another customer? or ... given that they pay you to build this stuff *for them and their business* a quick lesson in economics might be in order (you build, they pay ... they screw it up, you fix it, they pay some more) >> 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). that would imply some specific code in the script, which, given the script is owned by the given user account, is a waste of time developing ... the given user can just edit the script (unless you use an encoder, and even then it's not impossible ... besides the user could still replace the script wholesale) or maybe you're able to make it read only for them, in which case you might start by looking into: http://php.net/manual/en/function.php-sapi-name.php > 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 >>> >>> >>> >> >> > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
