{"vuid":"VU#929115","idnumber":"929115","name":"PHP fails to properly parse the headers of HTTP POST requests","keywords":["PHP","HTTP POST request","headers"],"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.","clean_desc":"PHP is a popular scripting language in widespread use. For more information about PHP, see http://www.php.net/manual/en/faq.general.php. 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.","resolution":"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\nUntil 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\n   Deny from all\n</Limit> \nNote that an existing configuration and/or .htaccess file may have parameters contradicting the example given above. Disable vulnerable service\nUntil 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.","workarounds":"","sysaffected":"","thanks":"Thanks to e-matters Security for reporting this vulnerability.","author":"This document was written by Ian A Finlay.","public":["http://www.php.net/release_4_2_2.php","http://online.securityfocus.com/archive/1/283532","http://online.securityfocus.com/archive/1/283533","http://www.securityfocus.com/bid/5278"],"cveids":["CVE-2002-0717"],"certadvisory":"CA-2002-21","uscerttechnicalalert":null,"datecreated":"2002-07-22T13:43:11Z","publicdate":"2002-07-22T00:00:00Z","datefirstpublished":"2002-07-22T14:59:48Z","dateupdated":"2003-05-30T17:21:44Z","revision":36,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"15","cam_exploitation":"10","cam_internetinfrastructure":"17","cam_population":"10","cam_impact":"18","cam_easeofexploitation":"15","cam_attackeraccessrequired":"20","cam_scorecurrent":"42.525","cam_scorecurrentwidelyknown":"47.5875","cam_scorecurrentwidelyknownexploited":"57.7125","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":42.525,"vulnote":null}