Vulnerability in PHP Clarification?
Can anyone clarify this a bit? I see that they state that 4.2.0 and 4.2.1 are vulnerable. If you goto the link provided http://security.e-matters.de/advisories/012002.html It states that the older versions are vulnerable and that the 4.2 tree is not affected. Not to mention that link is dated 5months old! What is right? -Chris - Original Message - From: CERT Advisory [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 22, 2002 4:09 PM Subject: CERT Advisory CA-2002-21 Vulnerability in PHP -BEGIN PGP SIGNED MESSAGE- CERT Advisory CA-2002-21 Vulnerability in PHP Original release date: July 22, 2002 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected * Systems running PHP versions 4.2.0 or 4.2.1 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. I. Description 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 II. 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. III. 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
Re: Vulnerability in PHP Clarification?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.php.net Has a security warning posted on their site. It affects 4.2.0 and 4.2.1. An update to 4.2.2 is highly recommended. chris wrote: | Can anyone clarify this a bit? I see that they state that 4.2.0 and 4.2.1 | are vulnerable. | If you goto the link provided | http://security.e-matters.de/advisories/012002.html | It states that the older versions are vulnerable and that the 4.2 tree is | not affected. | Not to mention that link is dated 5months old! | What is right? | | -Chris | | | - Original Message - | From: CERT Advisory [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Sent: Monday, July 22, 2002 4:09 PM | Subject: CERT Advisory CA-2002-21 Vulnerability in PHP | | | | |-BEGIN PGP SIGNED MESSAGE- | |CERT Advisory CA-2002-21 Vulnerability in PHP | | Original release date: July 22, 2002 | Last revised: -- | Source: CERT/CC | | A complete revision history can be found at the end of this file. | |Systems Affected | | * Systems running PHP versions 4.2.0 or 4.2.1 | |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. | |I. Description | | 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 | |II. 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. | |III. 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
