PHP fails to properly parse the headers of HTTP POST requests
Vulnerability Note VU#929115
Original Release Date: 2002-07-22 | Last Revised: 2003-05-30
Overview
A vulnerability has been discovered in PHP. This vulnerability could be used by a remote attacker to execute arbitrary code or crash PHP and/or the web server.
The vulnerability occurs in the portion of PHP code responsible for handling file uploads, specifically multipart/form-data. By sending a specially crafted POST request to the web server, an attacker can corrupt the internal data structures used by PHP. Specifically, an intruder can cause an improperly initialized memory structure to be freed. In most cases, an intruder can use this flaw to crash PHP or the web server. Under some circumstances, an intruder may be able to take advantage of this flaw to execute arbitrary code with the privileges of the web server.
You may be aware that freeing memory at inappropriate times in some implementations of malloc and free does not usually result in the execution of arbitrary code. However, because PHP utilizes its own memory management system, the implementation of malloc and free is irrelevant to this problem.
Stefan Esser of e-matters GmbH has indicated that intruders cannot execute code on x86 systems. However, we encourage system administrators to apply patches on x86 systems as well to guard against denial-of-service attacks and as-yet-unknown attack techniques that may permit the execution of code on x86 architectures.
This vulnerability was discovered by e-matters GmbH and is described in detail in their advisory. The PHP Group has also issued an advisory. A list of vendors contacted by the CERT/CC and their status regarding this vulnerability is available in VU#929115.
Although this vulnerability only affects PHP 4.2.0 and 4.2.1, e-matters GmbH has previously identified vulnerabilities in older versions of PHP. If you are running older versions of PHP, we encourage you to review http://security.e-matters.de/advisories/012002.html.
Impact
A remote attacker can execute arbitrary code on a vulnerable system. An attacker may not be able to execute code on x86 architectures due to the way the stack is structured. However, an attacker can leverage this vulnerability to crash PHP and/or the web server running on an x86 architecture.
Solution
Apply a patch from your vendor
Appendix A contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. Please contact your vendor directly.
Upgrade to the latest version of PHP
If a patch is not available from your vendor, upgrade to version 4.2.2.
Deny POST requests
Until patches or an update can be applied, you may wish to deny POST requests. The following workaround is taken from the PHP Security Advisory:
If the PHP applications on an affected web server do not rely on HTTP POST input from user agents, it is often possible to deny POST requests on the web server.
In the Apache web server, for example, this is possible with the following code included in the main configuration file or a top-level .htaccess file:
<Limit POST> Order deny,allow Deny from all </Limit>
Note that an existing configuration and/or .htaccess file may have parameters contradicting the example given above.
Disable vulnerable service
Until you can upgrade or apply patches, you may wish to disable PHP. As a best practice, the CERT/CC recommends disabling all services that are not explicitly required. Before deciding to disable PHP, carefully consider your service requirements.
FreeBSD does not include any version of PHP by default, and so is not vulnerable; however, the FreeBSD Ports Collection does contain the PHP4 package. Updates to the PHP4 package are in progress and a corrected package will be available in the near future.
Vendor Information
The vendor has not provided us with any further information regarding this vulnerability.
Addendum
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.
Mandrake Linux does not ship with PHP version 4.2.x and as such is not vulnerable. The Mandrake Linux cooker does currently contain PHP 4.2.1 and will be updated shortly, but cooker should not be used in a production environment and no advisory will be issued.
Vendor Information
The vendor has not provided us with any further information regarding this vulnerability.
Addendum
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.
IBM is not vulnerable to the above vulnerabilities in PHP. We do supply the PHP packages for AIX through the AIX Toolbox for Linux Applications. However, these packages are at 4.0.6 and also incorporate the security patch from 2/27/2002.
Vendor Information
The vendor has not provided us with any further information regarding this vulnerability.
Addendum
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.
Caldera OpenLinux does not provide either vulnerable version (4.2.0, 4.2.1) of PHP in their products. Therefore, Caldera products are not vulnerable to this issue.
Vendor Information
The vendor has not provided us with any further information regarding this vulnerability.
Addendum
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.
The TSL team states that none of the versions of the Trustix Secure Linux distribution is vulnerable to the php 4.2.{0,1} vulnerability (CA-2002-21) as none of the TSL versions is shipped with php 4.2.x.
Vendor Information
The vendor has not provided us with any further information regarding this vulnerability.
Addendum
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.
SOURCE: Compaq Computer Corporation, a wholly-owned subsidiary of Hewlett-Packard Company and Hewlett-Packard Company HP Services Software Security Response Team
x-ref: SSRT2300 php post requests
At the time of writing this document, Compaq is currently investigating the potential impact to Compaq's released Operating System software products.
As further information becomes available Compaq will provide notice of the availability of any necessary patches through standard security bulletin announcements and be available from your normal HP Services supportchannel.
Vendor Information
The vendor has not provided us with any further information regarding this vulnerability.
Addendum
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.
SGI acknowledges the PHP vulnerabilitity reported by CERT and is currently investigating. PHP does not currently ship as part of IRIX so SGI can confirm that base IRIX is not vulnerable. No further information is available at this time.
For the protection of all our customers, SGI does not disclose, discuss or confirm vulnerabilities until a full investigation has occurred and any necessary patch(es) or release streams are available for all vulnerable and supported IRIX operating systems. Until SGI has more definitive information to provide, customers are encouraged to assume all security vulnerabilities as exploitable and take appropriate steps according to local site security policies and requirements. As further information becomes available, additional advisories will be issued via the normal SGI security information distribution methods including the wiretap mailing list on http://www.sgi.com/support/security/.
Vendor Information
The vendor has not provided us with any further information regarding this vulnerability.
Addendum
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.