php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #20580 security vulnerability
Submitted: 2002-11-22 12:56 UTC Modified: 2002-11-22 12:58 UTC
From: dendler at idefense dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 4.2.3 OS: all
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dendler at idefense dot com
New email:
PHP Version: OS:

 

 [2002-11-22 12:56 UTC] dendler at idefense dot com 
In accordance with iDEFENSE's security vulnerability disclosure policy (www.idefense.com/disclosure.html), we wanted to bring a security issue to your attention.  Please acknowledge receipt of this information so we can work toward a public disclosure date that is convenient to you in building a fix.

Attackers are able to disclose arbitrary files by exploiting a vulnerability in the PHP Group's PHP project's handling of file uploads. This vulnerability is a variation of a vulnerability that was discovered in early April of 2000 (CVE-2000-0860) that affects all versions of PHP prior to version 4.0.3. 

Scripts that utilize the legacy method for handling file uploads follow these steps: When registering a global variable php_mime_split() calls safe_php_register_variable(). This function in turn runs a check with is_protected_variable(), and if it's not dealing with a protected variable will then call php_register_variable(). is_protected_variable() calls zend_hash_exists() on the rfc1867_protected_variables hash. The php_mime_split() function adds protected variables to the hash with a call to zend_hash_add(). If a user tries to register a variable that is protected (such as the uploaded file's path) the request will be denied since the requested variable name exists in the rfc1867_protected_variables hash. 

The problem stems from the fact that php_register_variable_ex() manipulates the variable name before it is stored. Leading spaces are removed, and spaces and dots are swapped with underscores. Therefore, if the variable 'file_path' is protected, an attacker can submit ' file_path', thereby bypassing the security checks from the Zend hash functions. However, php_register_variable_ex() will transform ' file_path' into 'file_path' and register it as a global variable. 

An attacker can utilize this vulnerability to modify the value of the temporary path of an uploaded file to point to another arbitrary file. File uploads are generally handled by either copying uploaded temporary files to another (normally web accessible) directory or by storing them within a database. In either case, an attacker can cause disclosure of arbitrary system files.  
Sources: iDEFENSE Labs, Nov. 06, 2002  

Analysis: (iDEFENSE US) Any remote user can exploit this vulnerability against a script running in an affected server provided that the script is using the legacy register_globals approach to uploaded file management as opposed to the new method that stores file info in the $_FILES array. Successful exploitation of the above-described vulnerability can result in: 
? Disclosure of PHP code. 
? Disclosure of database authentication data. 
? Disclosure of sensitive files on the target server. 
PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. More information is available at http://www.php.net. 

Detection: iDEFENSE has verified the existence of this vulnerability in PHP version 4.2.2. It is suspected and reported that all versions between 4.0.3 and 4.2.3 inclusive are vulnerable. To determine if the vulnerability exists in a specific implementation experiment with the following snippet of code: 

<html>
<body>
    <form method="POST" enctype="multipart/form-data">
        File 1: <input type="file" name="file1"><br>
        File 2: <input type="file" name="file2"><p>
        <!-- we will overwrite the location for file2 -->
        <input type="hidden" name="  file2" value="/evil/file/location">
        <input type="submit">
    </form>
    <hr>
    <?
        echo "File1 location: $file1 <br>\n";
        echo "File2 location: $file2 <br>\n";
    ?>
</body>
</html> 

The target server is vulnerable if after submitting the form the script prints: 

File2 location: /evil/file/location 

Workaround: Modify your upload handling scripts to utilize the $_FILES[] array method instead of the legacy register_globals method. More information is available at http://www.php.net/manual/en/features.file-upload.php. 

The code base for PHP v4.3.0pre2 appears to fix the problem since add_protected_variable() now calls normalize_protected_variable(), which removes leading spaces. This fix however does not asses the situation where a variable name contains an underscore, in which an attacker can still submit a '.' that will pass through normalize_protected_variable() but still get converted into an underscore by the normal variable register function. 

This change in the code base was committed into the CVS tree on October 7th, 2002 the details of which are available at http://marc.theaimsgroup.com/?l=php-cvs&m=103399103900385&w=2.  

David Endler, CISSP
Director, Technical Intelligence
iDEFENSE, Inc.
14151 Newbrook Drive
Suite 100
Chantilly, VA 20151
voice: 703-344-2632
fax: 703-961-1071

dendler@idefense.com
www.idefense.com

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-22 12:58 UTC] derick@php.net 
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the original bug instead.

Thank you for your interest in PHP.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 11:01:30 2024 UTC