Released
04/09/2000
(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 its impact)
Vulnerable
Almost any PHP program which provides file upload capability
Overview
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’.
Impact
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
Detail
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 ‘c:\hello.tmp)
$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.
Fix
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.