From: [EMAIL PROTECTED] Operating system: all PHP version: 4.2.3 PHP Bug Type: *General Issues Bug description: security vulnerability
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 [EMAIL PROTECTED] www.idefense.com -- Edit bug report at http://bugs.php.net/?id=20578&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20578&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20578&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20578&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20578&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20578&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=20578&r=support Expected behavior: http://bugs.php.net/fix.php?id=20578&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=20578&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=20578&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20578&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20578&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20578&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20578&r=isapi
