PHP PHPInfo Large Input Cross-Site Scripting Vulnerability PHP is prone to a cross-site scripting vulnerability. This issue is due to a failure in the application to properly sanitize user-supplied input. An attacker may leverage this issue to have arbitrary script code executed in the browser of an unsuspecting user in the context of the affected site. This may help the attacker steal cookie-based authentication credentials and launch other attacks. Published: Apr 03 2006 12:00AM Our last stable release 4.4.0-r4 is affected Patch : http://marc.theaimsgroup.com/?l=php-cvs&m=114374620416389&w=2
not sure files/php4.4.0-phpinfo_xss.patch (nov. 2005) corrects it, the provided patch on PHP's CVS (5 days ago) is so different... well, it's possible. Please someone can help me check that ?
Uh, it this really about dev-php/php *only*? If so, well it's dead and completely unmaintained, can be just package.masked. (Will require mips support to be dropped, since mips didn't keyword any of the new dev-lang/php ebuilds).
This particular issue was only fixed in PHP CVS for HEAD and the PHP5_1 branch, not for the PHP4_4 one, which would suggest that the latest PHP 4.4.2 isn't affected by this (dev-lang/php-4.4.2), not sure about it though, could also be that they forgot about it. Is there any simple POC around? Thanks, best regards, CHTEKK.
(In reply to comment #3) > This particular issue was only fixed in PHP CVS for HEAD and the PHP5_1 branch, > not for the PHP4_4 one, which would suggest that the latest PHP 4.4.2 isn't securityfocus says PHP 4.4.2 is vulnerable. > affected by this (dev-lang/php-4.4.2), not sure about it though, could also be dev-lang or dev-php ? (maybe both of them ? don't know) > that they forgot about it. Is there any simple POC around? don't know. :(
Adding other information from jslootbeek (bug #129311), with an exploit (thanks to him). See [1] The vuln affects both dev-lang/php and dev-php/php. Sorry for having missing one of them in the summary : i haven't read the code for info.php in dev-lang/php, which is nearly the same. I have only checked that our dev-php/php is affected. The vuln has been corrected 10 days ago in PHP CVS (5_1). See [2] for the exact diff. Branch 4_4 (which IS vulnerable [3]) was not patched. [1] http://securityreason.com/achievement_securityalert/34 [2] http://cvs.php.net/viewcvs.cgi/php-src/ext/standard/info.c?r1=1.260&r2=1.261 [3] http://www.securityfocus.com/bid/17362
*** Bug 129311 has been marked as a duplicate of this bug. ***
I've talked with upstream, PHP 4.4 is vunlerable and a patch will be committed to CVS over the next few days I hope, they haven't yet had time to make it. Same goes for the safe_mode copy() bug. Wrt PHP 5.1, a 5.1.3RC3 will be released soon, and then the final 5.1.3. As none of the vulnerabilities is in any way critical, I'll wait on 5.1.3 to fix all the issues in the 5.1 branch, and for the 4.4 branch I'll release a 4.4.2-r1 package, as soon as all the vulnerabilities have been fixes there too. I estimate all this can take up to 1-2 weeks, depends all on upstream. Best regards, CHTEKK.
PHP team, I suppose you'll release this concurrently with bug 127939
(In reply to comment #8) > PHP team, I suppose you'll release this concurrently with bug 127939 Indeed. So the EAT for this (and subsequently the other one) is: as soon as this is fixed in the PHP4_4 branch. All other bugs were in the meantime, I'm just waiting for this one for PHP 4.4, it should come soon, then I'll go with 4.4.2-r2 and 5.1.2-r2 (as a 5.1.3 final may be too far away, no real ETA on that). Best regards, CHTEKK.
Setting it to upstream until new PHPs are released
Fixed, see bug #131135 for stabilization instructions and then close this when that one is closed too. Best regards, CHTEKK.
Common GLSA with 131135
GLSA 200605-08