Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: (SRADV00001) Arbitrary file disclosure through PHP file upload (fwd)
From: "Wouter de Jong (widexs.nl)" <wouter () WIDEXS NL>
Date: Mon, 4 Sep 2000 22:26:44 +0200

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.



  By Date           By Thread  

Current thread:
  • Re: (SRADV00001) Arbitrary file disclosure through PHP file upload (fwd) Wouter de Jong (widexs.nl) (Sep 05)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]