Description of Problem: I've a php script which uploads files. These files arrive on the server (after move_uploaded_file()) with ugo execute permission set. This can't be good. Version-Release number of selected component (if applicable): php-4.0.6-15 apache-1.3.22-6 How Reproducible: Always. Steps to Reproduce: Upload file with php, save with move_uploaded_file. Expected Results: I'd expect u=rw,g=rw,o=r permissions (group rw allows "collaboration" between webserver and others.) Additional Information: Am using the default umask in the apache config file. (i.e. umask never specified.) My script does contain the code: // Make the temp directory. $mask = umask(05002); // Turn off setuid, sticky bit, and 'other' write mkdir($temppath, 02774); // Allow anybody to read but not decend umask($mask); Later, the uploaded file is moved into $temppath with move_uploaded_file(). This shouldn't matter, but.... (Other files created with fopen, fwrite, fclose are not executable.) See also?: Bug#:41229 What is the default upload directory (/etc/php.ini says it's "the system default") so I can add an appropriate umask to the apache configuration file? Maybe the default apache umask should be && 0111? P.S. It seems a little uncivil to be reporting security problems in what amounts to a public forum. Is there another way? (I assigned priority "low" as it takes another exploit to take advantage of this behavior.)
Presently permissions on uploaded files are: -rwxr-xr-x
You'd only be able to exploit this if your script saved uploaded files into somewhere that the webserver would execute them. If you _are_ doing this then you should stop, since you can make an exploit without requiring execute permissions: PHP, mod_perl, mod_python, etc don't require their scripts be executable. It is, however, a little strange that they arrive with execute permissions set, and it should probably be fixed. In the meantime you can always fix this in your script by chmod()ing them (see http://www.php.net/manual/en/function.chmod.php). By the way, using umask() in your script probably won't work since PHP downloads the file before any of your code executes.
Thanks for the report. This is a mass bug update; since this release of Red Hat Linux is no longer supported, please either: a) try and reproduce the bug with a supported version of Red Hat Enterprise Linux or Fedora Core, and re-open this bug as appropriate after changing the Product field, or, b) if relevant, try and reproduce this bug using the current version of the upstream package, and report the bug upstream.