Bugzilla Bug 128883

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