From: php-online at cyberblue dot org dot uk Operating system: MacOS/Redhat PHP version: 4.3.3 PHP Bug Type: Feature/Change Request Bug description: Circumventing safe mode to extend file operations
Description: ------------ In safe mode the httpd process (apache uid) can create files/directories using a script in a 0777 directory both owned by the user (user uid). If the httpd tries to create files/dirs in a newly created directory then we will get the familiar warning: <i>Warning:</i> <b>[File/Dir operation()]</b>: SAFE MODE Restriction in effect. The script whose uid is <b>user</b> is not allowed to access <b>[apache_owner_dir/file]</b> owned by uid <b>apache</ b> The fact that httpd can create new files allows us to copy a script containing file (and other!) operations that can then be used to perform operations with a script owned by apache. eg: file_ops.php (user uid) -- copy--> hack_file_ops.php (apache uid). This would avoid the above warning. Used in conjuction with the HTTP forwarding header [ie header( "Location: http://.../hack_file_ops.php";);] this file can be called upon from normal scripts to perform operations on files/dirs owned by apache while in safe mode, thus circumventing its restrictions. This is good to extend functionality when a hosting provider limits code execution by turning on safe mode. This means many ready made php packages can be modified to work (well, those that need to do lots of file/ directory manipulation :). It could also be used to play around with other entities owned by apache/www/ nobody/httpd uid. such as the davlocks/proxy directories... It would make sense to allow a script access to a 0777 directory whether it was in safe mode or not - certainly file manipulation within the web root should be allowed but for now this work around is ok, but hacky. The worrying part is it does allow a small security hole but its ramifications (for the most part) seem to be limited. If apache cannot access the davlock directory will it be happy? laters, Andi -- Edit bug report at http://bugs.php.net/?id=26375&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26375&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26375&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26375&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26375&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26375&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=26375&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=26375&r=support Expected behavior: http://bugs.php.net/fix.php?id=26375&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=26375&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=26375&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26375&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26375&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26375&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26375&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=26375&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26375&r=float
