I believe that the security team has seen the vulnerability myself, it should be publically available tomorrow. PHP 4.3.8 is in the tree already, as ~arch. For all arches (alpha amd64 hppa ia64 ppc s390 sparc x86): you need to test and stabilize dev-php/php, dev-php/mod_php, dev-php/php-cgi how to test: 1. ebuild php-4.3.8.ebuild package 2. make sure your php.ini does NOT load any extra extensions (turck mmcache etc.) 3. cd /var/tmp/portage/php-4.3.8/work/php-4.3.8 ; make test You should get a result like the following: ===================================================================== TIME END 2004-07-13 23:14:11 ===================================================================== TEST RESULT SUMMARY --------------------------------------------------------------------- Exts skipped : 38 Exts tested : 49 --------------------------------------------------------------------- Number of tests : 596 Tests skipped : 107 (18.0%) Tests warned : 0 ( 0.0%) Tests failed : 2 ( 0.3%) Tests passed : 487 (81.7%) --------------------------------------------------------------------- Time taken : 271 seconds ===================================================================== ===================================================================== FAILED TEST SUMMARY --------------------------------------------------------------------- Bug #16069 [ext/iconv/tests/bug16069.phpt] xslt_set_object function [ext/xslt/tests/xslt_set_object.phpt] ===================================================================== the number of tests will vary depending on what your USE flags are. there are a number of tests that _do_ fail upstream, due to known bugs, but have been broken for a long time, mainly as examples of what PHP doesn't do. if you get larger numbers of failed tests, please post the output like the above here.
I notice that allow_url_fopen defaults to On now (updated since 4.3.4-r4) in /etc/php/cli-php4/php.ini ; Whether to allow the treatment of URLs (like http:// or ftp://) as files. -; allow_url_fopen = On -; Closed for security - <robbat2@gentoo.org> -allow_url_fopen = Off +allow_url_fopen = On Was that intentional?
Security Fixes : * Fixed strip_tags() to correctly handle '\0' characters. (CAN-2004-0595 http://security.e-matters.de/advisories/122004.html) * Improved stability during startup when memory_limit is used. (CAN-2004-0594 http://security.e-matters.de/advisories/112004.html) * Replace alloca() with emalloc() for better stack protection. * Added missing safe_mode checks inside ftok and itpc. * Fixed address allocation routine in IMAP extension. (bug #28963) * Prevent open_basedir bypass via MySQL's LOAD DATA LOCAL (bug #28632) Target keywords are : dev-php/php : "alpha amd64 hppa ia64 ppc s390 sparc x86" dev-php/mod_php : "alpha amd64 hppa ia64 ppc s390 sparc x86" dev-php/php-cgi : "alpha hppa ppc sparc x86" I suppose the regression on url_fopen was unintentional and will probably be fixed, so I let this at [ebuild] status.
It's deliberate that the fopen patch isn't applied to the CLI version of PHP. See line #566 of php-sapi.eclass. Best regards, Stu
Thnaks Stuart for the clarification. Arches: please test and mark stable the three packages according to above target keywords.
security: CAN-2004-0595 is marked as a moderate vulnerability only, but due to the extremely wide use of strip_tags, it is a LOT more dangerous. I've pointed out one of the extremely damaging cases to Kurt when he first contacted me about the vulnerability.
GLSA drafted
LWN just posted their report on the vulnerability: http://lwn.net/Articles/93581/ Kudos for being ahead of the game.
Stable on sparc
Stable on ppc
From: s.esser@e-matters.de Subject: Advisory 11/2004: PHP memory_limit remote vulnerability Date: July 13, 2004 6:53:29 PM EDT To: vulnwatch@vulnwatch.org, full-disclosure@lists.netsys.com, bugtraq@securityfocus.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 e-matters GmbH www.e-matters.de -= Security Advisory =- Advisory: PHP memory_limit remote vulnerability Release Date: 2004/07/14 Last Modified: 2004/07/14 Author: Stefan Esser [s.esser@e-matters.de] Application: PHP <= 4.3.7 PHP5 <= 5.0.0RC3 Severity: A vulnerability within PHP allows remote code execution on PHP servers with activated memory_limit Risk: Critical Vendor Status: Vendor has released a bugfixed version. Reference: http://security.e-matters.de/advisories/112004.html Overview: PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. According to Security Space PHP is the most popular Apache module and is installed on about 50% of all Apaches worldwide. This figure includes of course only those servers that are not configured with expose_php=Off. During a reaudit of the memory_limit problematic it was discovered that it is possible for a remote attacker to trigger the memory_limit request termination in places where an interruption is unsafe. This can be abused to execute arbitrary code on remote PHP servers. Details: On the 28th June 2004 Gregori Guninski released his advisory about a possible remote DOS vulnerability within Apache 2 (CAN-2004-0493). This vulnerability allows tricking Apache 2 into acception arbitrary sized HTTP headers. Guninski and many others rated this bug as "Low Risk" for 32bit systems, but they did not take into account that such a bug could have a huge impact on 3rd party modules. After his advisory was released I reaudited PHP's memory_limit request termination, because this bug made it possible to reach the memory_limit at places that were never meant to be interrupted. After a possible exploitation path for Apache 2 servers was discovered and a working exploit was created, similar pathes were found and added to the proof of concept exploit that allowed exploitation of NON Apache 2 servers. (f.e. Apache 1.3.31) The idea of the exploit is simple. When PHP allocates a block of memory it first checks in the cache of free memory blocks for a block of the same size. If such a block is found it is taken from the cache otherwise PHP checks if an allocation would violate the memory_limit. In that case the request shutdown is triggered through zend_error(). (PHP < 4.3.7 aborts after the violating memory block is allocated) PHP contains several places where such an interruption is unsafe. An example for such places are those where Zend HashTables are allocated and initialised. This is performed in 2 steps and the initialisation step itself allocates memory before important members are correctly initialised. An attacker that is able to trigger the memory_limit abort within zend_hash_init() and is additionally able to control the heap before the HashTable itself is allocated, is able to supply his own HashTable destructor pointer. Several places within PHP where found where this action is performed on HashTables that actually get destructed by the request shutdown. One of such places is f.e. within the fileupload code, but is only triggerable on Apache 2 servers that are vulnerable to CAN-2004-0493, another one is only reachable if variables_order was changed to have the "E" in the end, a third one is within session extension which is activated by default but the vulnerability can not be triggered if the session functionality is not used. A fourth place is within the implementation of the register_globals functionality. Although this is deactivated by default since PHP 4.2 it is activated on nearly all servers that have to ensure compatibility with older scripts. Other places might exist in not default activated or 3rd party extensions. All mentioned places outside of the extensions are quite easy to exploit, because the memory allocation up to those places is deterministic and quite static throughout different PHP versions. The only unknown entity is the size of the environment vars array. But that is usually small and can be bruteforced with some kind of binary search algorithm. Additionally this information could leak to an attacker through an open phpinfo() page. If the admin used php.ini-recommended as configuration basis it is irrelevant anyway because the ENV array is not populated in that case. Because the exploit itself consist of supplying an arbitrary destructor pointer this bug is exploitable on any platform. (Except the system runs with non exec heap+stack protection) This includes systems running Hardened-PHP <= 0.1.2 because they have no protection of the HashTable destructor pointer. As a last word it should be said, that an attacker does not need to send 8/16/64MB (or whatever the memory_limit is) per attack. With POST requests it is quite easy to eat 100 (and more) times the amount of sent bytes. Proof of Concept: e-matters is not going to release an exploit for this vulnerability to the public. Disclosure Timeline: 07. July 2004 - Vendor-sec was informed about the fact that this vulnerability was found 14. July 2004 - Public Disclosure CVE Information: The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0594 to this issue. Recommendation: If you are running PHP with compiled in memory_limit support, it is strongly recommended that you upgrade as soon as possible to the newest version. Disabling memory_limit within your configuration can be considered a workaround, but leaves your site vulnerable to memory hungry PHP scripts or POST requests that create huge variables. If you are running PHP with Apache <= 2.0.49 ensure that you have the fix for CAN-2004-0493 applied. GPG-Key: http://security.e-matters.de/gpg_key.asc pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC Copyright 2004 Stefan Esser. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFA9Icab31XLTAExLwRAuvFAKCzOMXUnIaj0CkCW0GxXg08YErusACgmU8z 5d1swwTrHOVQLKmruY+pea0= =H98x -----END PGP SIGNATURE-----
From: s.esser@e-matters.de Subject: Advisory 12/2004: PHP strip_tags() bypass vulnerability Date: July 13, 2004 6:55:25 PM EDT To: vulnwatch@vulnwatch.org, full-disclosure@lists.netsys.com, bugtraq@securityfocus.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 e-matters GmbH www.e-matters.de -= Security Advisory =- Advisory: PHP strip_tags() bypass vulnerability Release Date: 2004/07/14 Last Modified: 2004/07/14 Author: Stefan Esser [s.esser@e-matters.de] Application: PHP <= 4.3.7 PHP5 <= 5.0.0RC3 Severity: A binary safety problem within PHP's strip_tags() function may allow injection of arbitrary tags in Internet Explorer and Safari browsers Risk: Moderate Vendor Status: Vendor has released a bugfixed version. Reference: http://security.e-matters.de/advisories/122004.html Overview: PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. According to Security Space PHP is the most popular Apache module and is installed on about 50% of all Apaches worldwide. This figure includes of course only those servers that are not configured with expose_php=Off. During an audit of the PHP source code a binary safety problem in the handling of allowed tags within PHP's strip_tags() function was discovered. This problem may allow injection of f.e. Javascript in Internet Explorer and Safari browsers. Details: Many sites stop XSS attacks by striping unsafe HTML tags from the user's input. PHP scripts usually implement this functionality with the strip_tags() function. This function takes a optional second parameter to specify tags that should not get stripped from the input. $example = strip_tags($_REQUEST['user_input'], "<b><i><s>"); Due to a binary safety problem within the allowed tags handling attacker supplied tags like: <\0script> or <s\0cript> will pass the check and wont get stripped. (magic_quotes_gpc must be Off) In a perfect world this would be no dangerous problem because such tags are either in the allowed taglist or should get ignored by the browser because they have no meaning in HTML. In the real world however MS Internet Explorer and Safari filter '\0' characters from the tag and accept them as valid. Quite obvious that this can not only lead to a number of XSS issues on sites that filter dangerous tags with PHP's strip_tags() but also on every other site that filters them with pattern matching and is not necessary running PHP. According to tests: - Opera - Konqueror - Mozilla - Mozilla Firefox - Epiphany are NOT affected by this. Proof of Concept: e-matters is not going to release an exploit for this vulnerability to the public. Disclosure Timeline: 26. June 2004 - Problem found and fixed in CVS 14. July 2004 - Public Disclosure CVE Information: The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0595 to this issue. Recommendation: Because Internet Explorer is out of all reason still the most used browser fixing this problem within your PHP version is strongly recommended. GPG-Key: http://security.e-matters.de/gpg_key.asc pub 1024D/3004C4BC 2004-05-17 e-matters GmbH - Securityteam Key fingerprint = 3FFB 7C86 7BE8 6981 D1DA A71A 6F7D 572D 3004 C4BC Copyright 2004 Stefan Esser. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQFA9Ic7b31XLTAExLwRAq6eAJ4j5AomlAJUhEHoDmLwCk4RqvJlVgCgqIN7 D9N75IutqIcoce4xqJTw6XQ= =Q5NT -----END PGP SIGNATURE-----
abused zhen's box and marked stable on amd64 ;)
stable on x86, after beating on it all day at work.
amd64: Sorry to bother you again, but we also need dev-php/mod_php-4.3.8 marked stable...
Stable on alpha.
glsa 200407-13
sorry, missed mod_php ... fixed for amd64 also pushed hppa into stable
