PHP 4.0 Apache Module Version May Display Script Source Code or May Use the Wrong Access Controls in Some Rare Cases
SecurityTracker Alert ID: 1000581|
SecurityTracker URL: http://securitytracker.com/id/1000581
(Links to External Site)
Date: Jan 15 2001
Disclosure of user information, User access via network|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): All versions of PHP 4.0 Apache module version|
Two problems have been reported with the Apache module version PHP 4.0: 1) Some PHP access controls could be subverted, and 2) Some PHP script code may be displayed instead of executed. Conditions required for these vulnerabilities are reportedly rare.|
As reported, PHP supports a configuration mechanism that allows users to configure PHP directives on a per-directory basis, usually done on Apache using .htaccess files. A bug in the Apache module version of PHP may allow an attacker to remotely form a special HTTP request that would cause PHP to serve the subsequent page with the wrong values for these directives. In certain situations, this could result in the incorrect access controls being applied.
PHP supports the ability to be installed but disabled by setting the configuration option 'engine = off'. A bug in the way the Apache module version of PHP handles multiple virtual host configurations might allow the 'engine = off' configuration option of one virtual host to be applied to other virtual hosts. Because the 'engine = off' option disables execution of PHP scripts, the source code of the scripts could end up being displayed to the end clients.
PHP 3.0 is reportedly not vulnerable. Other platform versions (non-Apache moduel) are reportedly not vulnerable.
It is reported that the exploitation of these problems requires certain rare situations. In order to take advantage of the first problem, the attacker must have knowledge of the site's directory structure and the values of the various PHP directives in each directory. In addition, the attacker must be able to issue two requests that are sequentially processed by the same Apache httpd process. If these conditions are met, the attacker could access a web page that would otherwise be restricted.|
In the second problem, an attacker could view PHP scripts on some virtual hosts.
The solution recommended in the report is to upgrade to PHP 4.0.4pl1, available at http://www.php.net/downloads.php|
Also, see the original report for some workarounds.
Vendor URL: www.php.net (Links to External Site)
Access control error, State error|
|Underlying OS: Linux (Any), UNIX (Any), Windows (Any)|
Source Message Contents
Subject: PHP Security Advisory - Apache Module bugs|
 PHP supports a configuration mechanism that allows users to configure
PHP directives on a per-directory basis. Under Apache, this is usually
done using .htaccess files. Due to a bug in the Apache module version of
PHP, remote 'malicious users' might be able to create a special HTTP
request that would cause PHP to serve the next page with the wrong values
for these directives. In certain (fairly rare) situations, this could
result in a security problem.
 PHP supports the ability to be installed, and yet disabled, by setting
the configuration option 'engine = off'. Due to a bug in the Apache module
version of PHP, if one or more virtual hosts within a single Apache server
were configured with engine=off, this value could 'propagate' to other
virtual hosts. Because setting this option to 'off' disables execution of
PHP scripts, the source code of the scripts could end up being sent to the
Even though in their worst-case situations these problems could have severe
implications, these worst-cases are rare. In order to take advantage of
problem #1, the attacker must have good knowledge of the structure of the
site, the values of the various PHP directives in each directory, and a way
that would help him exploit the bug using this knowledge. In addition, he
must also be lucky enough to perform the attack on the same Apache httpd
process that he exploits in a prior request, which can be very difficult to
do on a busy site.
Problem #2 is more serious, but because of its severity, it's most often
detected immediately. This problem also only affects a setup that has
multiple virtual hosts with some of them configured not to allow execution
of PHP scripts, which is pretty rare.
Affected Software Versions
All versions of PHP 4.0, from PHP 4.0.0 (and possibly earlier betas)
through PHP 4.0.4 are vulnerable to these problems. Note that only the
Apache module version of PHP is vulnerable - the CGI module as well as
other server modules are *NOT* affecgted.
PHP 3.0 is *NOT* affected.
The recommended solution is to upgrade to PHP 4.0.4pl1, available at
A workaround for problem #2 is to explicitly set 'engine=on' on all of the
virtual hosts that are supposed to serve PHP pages, if one or more virtual
hosts is configured with engine=off.
A partial workaround for problem #1 is to disallow 'OPTIONS' requests.
I'd like to thank James Moore, which, after hearing about the bug report,
managed to successfully reproduce it, and issue a pin-pointing problem
description, that helped solve the bug instantly.
Zeev Suraski <firstname.lastname@example.org>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
Go to the Top of This SecurityTracker Archive Page