Re: (SRADV00001) Arbitrary file disclosure through PHP file upload (fwd)

["Wouter de Jong (widexs.nl)" <wouter () WIDEXS NL>]

Hello,

I've tested the PHP security risk as described below, but it doesn't work
for me.

I tried it on several servers : Apache 1.3.12 with Apache 4.0.0 and PHP
4.0.1pl2 and PHP 4.0.2, all running in SAFE_MODE and track_vars 'on'. I
think SAFE_MODE is _the_ solution to play secure against this.

OUTPUT : (similar on all boxes, except for the UID's & script-location)
Warning: SAFE MODE Restriction in effect. The script whose uid is 502 is
not allowed to access /etc/passwd owned by uid 0 in
/www/www.maddog2k.nl/public_html/test/uploading.php on line 2

Warning: fopen("/etc/passwd","r") - Success in
/www/www.maddog2k.nl/public_html/test/uploading.php on line 2

Warning: Supplied argument is not a valid File-Handle resource in
/www/www.maddog2k.nl/HTML5/test/uploading.php on line 2


Code :
[HTML]
<INPUT TYPE="hidden" NAME="utest" VALUE="/etc/passwd">
<INPUT TYPE="hidden" NAME="utest_name" VALUE="c:\boot.ini">
<INPUT TYPE="hidden" NAME="utest_type" VALUE="text/plain">
<INPUT TYPE="hidden" NAME="utest_size" VALUE="2000">

[PHP]
$data = addslashes(fread(fopen($utest,"r"), filesize($utest)));
print "<PRE>$data</PRE>\n";

Met vriendelijke groet/With kind regards,

Wouter de Jong
Widexs BV

> ---------- Forwarded message ----------
> Date: Mon, 4 Sep 2000 00:11:57 +1000
> From: Secure Reality Advisories <create () SECUREREALITY COM AU>
> To: BUGTRAQ () SECURITYFOCUS COM
> Subject: (SRADV00001) Arbitrary file disclosure through PHP file upload
>
> =================================================
> Secure Reality Pty Ltd. Security Advisory #1 (SRADV00001)
> http://www.securereality.com.au
> =================================================
>
> [Title]
> Arbitrary file disclosure through PHP file upload
>
> [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.
>
> [Disclaimer]
> 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.