I came across this interesting piece, don't know how relevant it is, but just check it.
Arbitrary file disclosure through PHP file upload
(We found this particular issue a while ago but were planning to disclose it
at a later date once we had a chance to investigate its imact on most
popular PHP software. However, the issue was recently half found/disclosed
by a poster on the php-general mailing list, who didn't appear to realise
_Almost_ any PHP program which provides file upload capability
PHP is a feature heavy web scripting language that has become widely
popular. One of its many features is easy handling of file uploads from
remote browsers. This functionality is very commonly used, particularly in
photo gallery, auction and webmail style applications.
The way that PHP handles file uploads makes it simple to trick PHP
applications into working on arbitrary files local to the server rather than
files uploaded by the user. This will generally lead to a remote attacker
being able to read any file on the server that can be read by the user the
web server is running as, typically 'nobody'.
1. File disclosure
2. (1) will often lead to disclosure of PHP code
3. (2) will often lead to disclosure of database authentication data
4. (3) may lead to machine compromise
When files are uploaded to a PHP script, PHP receives the file, gives it a
random name and places it into a configured temporary directory. The PHP
script is given information about the file that was uploaded in the form of
4 global variables. Presuming the file field in the form was called 'hello',
the 4 variables would be:
$hello = Name of temporary file (e.g '/tmp/ASHDjkjbs')
$hello_name = Name of file when it was on the remote computer (e.g
$hello_type = Mime type of file (e.g 'text/plain')
$hello_size = Size of uploaded file (e.g 2000 bytes)
The temporary file is automatically deleted at the end of the execution of
the script so the PHP script usually needs to move it somewhere else. For
example, it might copy the file into a blob in a MySQL database.
The problem is actually in the way PHP behaves by default. Unless
deliberately configured otherwise (via register_globals = Off in php.ini)
the values specified in form fields upon a submit are auctomatically
declared by their form name as global variables inside the PHP script.
If I had a form with an input field like
<INPUT TYPE="hidden" NAME="test" VALUE="12">
When the PHP script is called to handle the form input, the global variable
$test is set. In my opinion this is a significant security risk, in fact,
I'll be posting quite a few security issues based around it in the coming
weeks). The problem is simple, cluttering the global namespace with user
defined input so destablizes the environment that it is almost impossible to
write in it securely.
Back to the issue at hand. Using the fact mentioned above, we can create the
four variables $hell, $hello_name, $hello_type, $hello_size ourselves using
form input like the following
<INPUT TYPE="hidden" NAME="hello" VALUE="/etc/passwd">
<INPUT TYPE="hidden" NAME="hello_name" VALUE="c:scary.txt">
<INPUT TYPE="hidden" NAME="hello_type" VALUE="text/plain">
<INPUT TYPE="hidden" NAME="hello_size" VALUE="2000">
This should lead the PHP script working on the passwd file, usually
resulting in it being disclosed to the attacker.
Unfortunately, I believe this style of problem to be impossible to fix with
the default behaviour/configuration of PHP, I'll be demonstrating this with
several adviories in the next few weeks.
My suggestion to all administrators of PHP enabled boxes is to change the
register_globals in php.ini to off, and switch track_vars to on. This will
however lead to most PHP scripts breaking. In the short term, disable any
PHP scripts you have that provide file upload functionality until the vendor
of those scripts can provide a fix/determine non vulnerability.
For PHP coders with little control over the configuration of the boxes they
work on. Hopefully track_vars has been enabled on the box. Check if 'hello'
is present in $HTTP_GET_VARS, $HTTP_POST_VARS or $HTTP_COOKIE_VARS, if it
is, ignore the input.
Advice, directions and instructions on security vulnerabilities in this
advisory do not constitute: an endorsement of illegal behaviour; a guarantee
that protection measures will work; an endorsement of any product or
solution or recommendations on behalf of Secure Reality Pty Ltd. Content is
provided as is and Secure Reality does not accept responsibity for any
damange or injury caused as a result of its use.