Just to add a little more to what Mr Jedi said, Only allowing php code of the choice, may also endup in infinite loops causing denial of service. Including that, they may attempt to establish connection with other machines, within the LAN or imagine bruteforcing SQL servers on the internet, or bannergrabbing for that matter. Having the "apache" or "nobody" privileges, the attacker could do: - privilege escalation by using local vulnerabilities. - destroy/ delete/ tamper the logfiles. - destroy / delete/ tamper the webpages of other customers. - use it as a launchpad to attack other machines. - use it for mailbombing / spam / DoS / DDoS / Warez / Bouncing. Regards -------- Muhammad Faisal Rauf Danka --- Jedi/Sector One <j@pureftpd.org> wrote: >On Thu, Apr 03, 2003 at 08:39:03AM +0200, Goran Krajnovic wrote: >> This is a bit pointless, IMHO. 99% of PHP installations run the PHP code with >> the user-id of the web server process (usually a low privilege user like >> 'nobody' or 'apache'). >[snip snip] >> If an attacker has the opportunity to execude PHP code of his choice on a >> target server [1], he does not need to exploit a buffer overflow in PHP just to >> get the privileges of the web server user > > You missed an important point. > > Hosting services offering a PHP interpreter to untrusted people rely on >PHP features to restrict their field of action. > > Specifically, the open_basedir and safe_mode features are a must to avoid >people going outside their home directory with PHP scripts. > > If arbitrary code can be run through a PHP vulnerability, these >restrictions disappear. People can walk through files that are supposed to >be inaccessible. > > Given that many people just chmod -R 777 their directories when their >script doesn't work and leave plaintext SQL passwords everywhere, this is >definitely ann issue. > > Also don't forget that all PHP extensions aren't always enabled. For >instance, the socket extension is typically disabled by most hosting service >providers for obvious reasons. > > Once and again, a vulnerability in the PHP interpreter can bypass this >restriction and gain access to other machines of the LAN, run DOS agents, etc. > > Of course, one shouldn't rely 100% on PHP userland security barriers, this >is where tools like NetBSD/OpenBSD's systrace can really add another >efficient layer of security. > >-- > __ /*- Frank DENIS (Jedi/Sector One) <j@42-Networks.Com> -*\ __ > \ '/ <a href="http://www.PureFTPd.Org/";> Secure FTP Server </a> \' / > \/ <a href="http://www.Jedi.Claranet.Fr/";> Misc. free software </a> \/ _____________________________________________________________ --------------------------- [ATTITUDEX.COM] http://www.attitudex.com/ --------------------------- _____________________________________________________________ Select your own custom email address for FREE! Get you@yourchoice.com w/No Ads, 6MB, POP & more! http://www.everyone.net/selectmail?campaign=tag
