Justtechjobs.com Find a programming school near you






Online Campus Both


php-developer-list | 2000111

Fwd: [PHP-DEV] PHP Security Advisory - File Uploads From: Andi Gutmans (andi <email protected>)
Date: 11/13/00

OK I dug out the security advisory Zeev wrote a while ago on how it is best
to get uploaded files. Maybe this should go into the manual? In any case, I
still find it weird that the error message comes from Apache and not PHP
(which makes it harder to blame PHP) but there might be a reason.
Do you want to try and use move_uploaded_file() function instead of copy()?
And $HTTP_POST_FILES[]? Or are you doing this already?

Andi

Date: Mon, 11 Sep 2000 07:13:22 +0300
>To: BUGTRAQ <email protected>
>From: Zeev Suraski <zeev <email protected>>
>Cc: group <email protected>, php-dev <email protected>
>Subject: [PHP-DEV] PHP Security Advisory - File Uploads
>
>Problem
>========
>
>PHP supports RFC 1867 based file uploads. PHP saves uploaded files in a
>temporary directory on the server, using a temporary name. This temporary
>name is exposed to the PHP script as $FOO, where "FOO" is the name of the
>file input tag in the submitted form. Many PHP scripts process $FOO
>without taking measures to ensure that it is in fact a file that resides
>in a temporary directory. It's possible for a remote attacker to supply
>arbitrary file names as values for FOO, by submitting a standard form
>input tag by that name, and thus cause the PHP script to process arbitrary
>files.
>
>
>Impact
>=======
>
>The impact varies among different scripts, and depends on the action that
>the script performs on the uploaded file. Note that the actions that are
>performed on the uploaded file are (usually) being done with the
>permissions of the Web server user (usually 'nobody').
>
>
>Affected software versions
>==========================
>
>The problem is not in the source code of PHP, and is thus not related to
>any particular version of PHP; However, many PHP scripts may suffer from
>it, because there was no standard, easy way of testing whether a certain
>file is indeed a temporary uploaded file, or any other file on the
>system. This means that the previous posts on Bugtraq were not accurate -
>there's no way to make a patch for PHP that prevents scripts from being
>vulnerable to this exploit, the logic in the scripts themselves has to be
>modified.
>Note that prior to PHP 4.0, there is no way to turn 'register_globals'
>off, thus eliminating the ability of remote attackers to define variables
>in PHP's global scope (it's possible to prevent PHP 3.0 from processing
>HTTP variables completely by setting gpc_order to "" in php.ini, but
>there's no convenient way to access HTTP data that way).
>
>
>Solution
>========
>
>Never trust any input that may be coming from the remote user. Always
>test whether the variable you expect to contain the path of an upload
>file, actually contains a file path of a temporary file in the system.
>
>It is strongly recommended to turn register_globals off if possible. If
>register_globals is off, you can safely check $HTTP_POST_VARS[] for
>information about the upload files (see below). If register_globals is
>kept on, one must realize that any variable in the global scope might be
>overwritten by remote user input.
>
>
>Software Updates
>==================
>
>New versions of PHP have been packaged (4.0.3RC1 and 3.0.17RC1), to make
>it easier to secure scripts from this vulnerability. They include a new
>function that make it easy to determine whether a certain filename is a
>temporary uploaded file or not:
>
>/* Test whether a file is an uploaded file or not */
>is_uploaded_file($path);
>
>
>PHP 4.0.3 also features a new convenience function:
>
>/* Move an uploaded file to a new location. If the file is not
> * a valid upload file, no action will take place.
> */
>move_uploaded_file($path, $new_path);
>
>In addition, as of PHP 4.0.3, it's safe to use
>$HTTP_POST_FILES["FOO"]["tmp_name"] - which cannot be written to by any
>remote user input, even when register_globals is on.
>
>The new versions are currently in testing, and thus have the RC tag.
>
>PHP 4.0.3RC1:
>http://www.php.net/do_download.php?download_file=php-4.0.3RC1.tar.gz
>
>PHP 3.0.17RC1 (upgrading to PHP 4.0 is strongly recommended):
>http://www.php.net/distributions/php-3.0.17RC1.tar.gz
>
>
>Further Information
>===================
>
>Consult the PHP manual, particularly the 'PHP variables' section of
>http://www.php.net/manual/language.variables.predefined.php
>
>
>Acknowledgements
>==================
>
>- Shaun Clowes from SecureReality, for pointing out this issue in the
> first place and helping in its assessment.
>- Jon Ribbens, for helping out in the discussion about how to address this
> issue (albeit in a fairly ugly manner).
>- The PHP documentation team, and especially Lars Torben Wilson, for
> updating the online manual.
>
>PHP Group
>http://www.php.net/
>--
>Zeev Suraski <zeev <email protected>>
>http://www.zend.com/
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
>For additional commands, e-mail: php-dev-help <email protected>
>To contact the list administrators, e-mail: php-list-admin <email protected> 

---
Andi Gutmans <andi <email protected>>
http://www.zend.com/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>