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):
Steps to Reproduce:
Upload file with php, save with move_uploaded_file.
I'd expect u=rw,g=rw,o=r permissions (group rw allows "collaboration"
between webserver and others.)
Am using the default umask in the apache config file. (i.e. umask
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
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
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
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.