Lucene search
K

SRADV00001.txt

🗓️ 11 Sep 2000 00:00:00Reported by Secure RealityType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 21 Views

Arbitrary file disclosure via PHP file uploads poses significant security risks to web applications.

Code
`=================================================  
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.  
`

Data

Build on a solid foundation with Vulners data

We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data

Api

Power your application with Vulners API

The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access

App

Assess and manage vulnerabilities with Vulners tools

Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation