Date: Mon, 31 Oct 2005 15:22:51 -0600
From: Matthew Murphy <mattmurphy@...rr.com>
To: Stefan Esser <sesser@...dened-php.net>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: Advisory 18/2005: PHP Cross Site Scripting
 (XSS)	Vulnerability in phpinfo()

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

Stefan Esser wrote:
> Unfortunately for you, the CVS commit you quote has nothing todo with
> the XSS vulnerability in my advisory.
> My advisory covers "Input Validation Part 1" which you can read here
> 
> http://viewcvs.php.net/viewcvs.cgi/php-src/ext/standard/info.c.diff?r1=1.245.2.2&r2=1.245.2.3
> 
> I hope this is enough to convince you... (because your bug report has
> nothing todo with arrays not beeing escaped at all)

I don't want to claim credit for your research; I'm just trying to get
credit for my own.  Even if wholesale plagiarism isn't going down here
(and I feel like it's something awfully close) it's obvious that the two
pieces of broken code are susceptible to the same attack.  An
acknowledgement of the original report is *in order*, even if only to
show how the vulnerabilities are different (which you really haven't
shown as of yet).

Particularly given the fact that new versions of PHP patch *BOTH*
vulnerabilities (or attempt to, anyway), it only makes sense that both
reports are acknowledged.  Because you are an agent of the group, you
should also specifically acknowledge independent reports if you identify
a similar vulnerability.

If you look at the original scenario (my particular bad URL triggering
the particular scenario I cite with the misformed image tag) then yes,
it was closed.

Now, looking at the code we have for handling "stacked arrays", a simple
morph of the URL does the trick.  Change it from:

http://www.somesite.com/test.php?">(code)=x

to:

http://www.somesite.com/test.php?x[code]=

strip two bytes, transpose another, and you have a "new" vulnerability?

I would accept the explanation of a slipshod upstream fix pretty easily,
but for one issue: you are *part* of the team delivering the upstream
fixes.  I've said it before and I'll say it again: had your dev team
declared my initial report to be fixed (rather than taking the hostile
line of calling it "Bogus"), I would have *RIPPED THEM OPEN* on that
conclusion.  Clearly, it was not fixed, and a simple re-audit would've
revealed that fact.

Look at it from my point of view for a second:

A vendor issues an update without technical details in which two fixes
mysteriously appear (one of which happens to plug a prior report) for a
particular piece of code.  No reference to the prior report.  I'd be
after the vendor for a terrible attempt at a silent patch and for
finding a "related" exploit as a way out of acknowledging a reporter.
Problem is... you *ARE* the vendor.

> ps: And you do not need to convince me, that you should have credits for
> that other bug. And it is a pity that it needed such a long time to fix
> it. In the end it is just an XSS in a debugging feature and therefore it
> was not taken so serious. You should be happy, that we have started to
> even fix vulnerabilities in debugging tools.

Given comments from others that it still isn't fixed, there's another
issue here.  The Group's development processes tend to blur the line
between security and non-security bugs.  While I am glad to see that
there is finally a process independent of the bug db for reporting
holes, I take issue with the way incidental patching is handled.

Microsoft is getting repeatedly grilled for its practice of fixing
potentially unsafe code (like the recent UPnP hole) in new versions of
its OS and not studying or not acknowledging the security impact of its
coding errors.  In this case, the impact was a remotely-exploitable
buffer overflow, and that should've been fairly obvious.

The PHP group is doing the same thing.  Probably the only dev team out
there with a good understanding of how to approach these issues of
"potentially unsafe code" that turns out to be a security fix is
OpenBSD.  And it takes a lot for me to praise an effort that seems to be
going the way of djb's qmail in overzealously protecting its "no
vulnerabilities here" type claims.  My biases aside, that debate is for
another day and another venue.

I doubt I will ever see a credit from the PHP team.  Truth-be-told, I
don't care that much.  The problem I have with this is that the
priorities of your team seem to suddenly be shifting toward fixing
vulnerabilities in debugging tools at a time when it's convenient for
you.  There hasn't been any political or procedural shift on the team,
but it's become important to fix these holes because someone on the team
found one of them.

When you do research independently into code that you had a hand in
creating, that creates a really unfair standard if I as a third-party
researcher have to compete against you.  Not only do I have to worry
about a vendor screwing me over by claiming internal discovery, but now
they have someone they can attribute it to.  If you're going to work as
a major contributor to a project, you should refrain from publishing
independently about vulnerabilities found within its code.

That's not to say you can't claim credit, but it would be far less
difficult to handle from many different points of view if that was done
by way of an official announcement from the PHP Group, and not this
tangled mess of semi-official publication by you (a developer) and an
official, but buried set of "release notes".

Regards,
Matthew Murphy

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

iD8DBQFDZosrfp4vUrVETTgRA+/MAKC16YTabmuMvHhVDksTwkODXnXBXACgqcbx
uqrzHcsDjgmonzecCauei28=
=tlVS
-----END PGP SIGNATURE-----

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (3436 bytes)

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

Powered by blists - more mailing lists