[Full-disclosure] Re: Advisory 18/2005: PHP Cross Site Scripting (XSS) Vulnerability in phpinfo()

• Previous message: Paul Laudanski: "[Full-disclosure] phpbb 2.0.18 release"
• Next in thread: Stefan Esser: "Re: [Full-disclosure] Re: Advisory 18/2005: PHP Cross Site Scripting (XSS) Vulnerability in phpinfo()"
• Reply: Stefan Esser: "Re: [Full-disclosure] Re: Advisory 18/2005: PHP Cross Site Scripting (XSS) Vulnerability in phpinfo()"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 31 Oct 2005 13:21:46 -0600
To: Stefan Esser <sesser@php.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Stefan Esser wrote:
> Mr. Murphy, I don't know what your problem is, but the bug you refer to
> and that is described in the bug tracker post is not the bug the
> advisory contains. Just because you reported some XSS vulnerability in
> phpinfo() does not mean that you can claim credit for every phpinfo()
> XSS vulnerability that exists. So please simply shut up and go cry
> elsewhere.

CVS belies your claim. Have a look at the RCS file that your CVS viewer
generates:

http://cvs.php.net/diff.php/php-src/ext/standard/info.c?r1=1.252&r2=1.253&ty=u

For the change marked "Input Validation Part 2". It uses ENT_QUOTES
escaping as opposed to ENT_NOQUOTES escaping. The lack of escaping on
quotes in entity attributes is the *EXACT* issue my bug report illustrates.

I may have chosen to exploit it in a different manner, but they are the
*SAME* bug.

>>Next time, you could try giving me credit for my research as well.
>>Thanks.
>
>
> Yeah well... If you report the bug first you can get credit.

For the record, I did. CVE-2002-1954.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-1954

The references of mine in that report clearly document the ability to
evade your input filters on phpinfo() by using quotes.

*YOUR* team's broken fix left the vulnerability wide open. You changed
the code from:

if (expose_php && PG(html_errors)) {
    PUTS("<a href=\"http://www.php.net/\"><img border=\"0\" src=\"");
    if (SG(request_info).request_uri) {
        PUTS(SG(request_info).request_uri);
    }
    if ((ta->tm_mon==3) && (ta->tm_mday==1)) {
        PUTS("?="PHP_EGG_LOGO_GUID"\" alt=\"Thies!\" /></a>");
    } else {
        PUTS("?="PHP_LOGO_GUID"\" alt=\"PHP Logo\" /></a>");
    }
}

to:

if (expose_php && !sapi_module.phpinfo_as_text) {
    PUTS("<a href=\"http://www.php.net/\"><img border=\"0\" src=\"");
    if (SG(request_info).request_uri) {
        char *elem_esc = php_info_html_esc(SG(request_info).request_uri
TSRMLS_CC);
        PUTS(elem_esc);
        efree(elem_esc);
    }
    PUTS("?=");
    logo_guid = php_logo_guid();
    PUTS(logo_guid);
    efree(logo_guid);
    PUTS("\" alt=\"PHP Logo\" /></a>");
}

which fails to fix the vulnerability, though it eliminates a rather
interesting easter egg. It simply changes the scenario from something like:

info.php?x="><script>...</script>

to the more difficult, but not impossible to exploit:

info.php?x=" style="left:expression([code])

That second exploit works against *both* the original input validation
code that I reported the vulnerability against (10/12/02) and the code
that (until this last fix) was in your CVS. Clearly, the underlying
vulnerability (the fact that I can create my own HTML in your info
output) is *STILL* there until your last update. Once you added in the
fix for your "new and different" vulnerability (ENT_QUOTES in
php_info_html_esc()), the original hole is conveniently closed as well.

Had your team claimed to "fix" my original vulnerability report (rather
than suggesting a config workaround and calling it "Bogus"), I would
have exposed their huge error in a matter of minutes.

Your team wrote a broken fix, and rather than admitting it, you claimed
that there was a "new" vulnerability. I'd appreciate a retraction,
rather than arrogant and asinine character assassination attempts on
your part.

In addition, you've resorted to calling me "some troll" in other forums
in an attempt to spare your reputation at the expense of mine. Even
better, these forums are in languages that I do not speak. I received a
translation of your heise.de post via e-mail from a reader of my
original response.

For the record, Mr. Esser, I am not a troll. I have done solid,
accurate research for a few *YEARS*, and I would never resort to
character attacks against a legitimate claim. I also do research that
is my own, and on the few occasions where my research has been
re-discoveries of that done by others, I have been more than willing to
acknowledge that.

How about treating me like a human being, Stefan? You are capable of
that, right?

Regards,
Matthew Murphy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDZm7Jfp4vUrVETTgRA7KwAJ9K6I2W2VsGTKqzo7JmpazR8jU77ACgolY8
F5fzAMxEHFAfg/YI14hPeh4=
=9a4D
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

• application/x-pkcs7-signature attachment: S/MIME Cryptographic Signature

• Previous message: Paul Laudanski: "[Full-disclosure] phpbb 2.0.18 release"
• Next in thread: Stefan Esser: "Re: [Full-disclosure] Re: Advisory 18/2005: PHP Cross Site Scripting (XSS) Vulnerability in phpinfo()"
• Reply: Stefan Esser: "Re: [Full-disclosure] Re: Advisory 18/2005: PHP Cross Site Scripting (XSS) Vulnerability in phpinfo()"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]