[php-maint] Re: status of multiple vulnerabilities in php4/sarge: update

[Martin Schulze]

Hi Sean!

sean finney wrote:
> On Tue, Aug 15, 2006 at 10:12:23PM +0200, Martin Schulze wrote:
> > > +    - CVE-2005-3389: parse_str()/register_globals vulnerability
> > 
> > Uh?  Wtf?  Who the )(**A#&%% would execute parse_str() on remotely
> > provided data when PHP?  PHP applications parse the GET, POST and
> > Cookie data already.
> 
> i think it's not uncommon for php apps to call parse_str, though i'd
> argue that calling it with one argument (which seems to be the
> vector here) is asking for trouble in the first place.  i wouldn't
> say that it's incredibly secure, but then again i wouldn't say
> php is incredibly secure to begin with :/
> 
> i'm also not sure what getting to turn on register_globals will get you
> that passing data to parse_str won't already get you in the first place,
> since if they call parse_str on something you supply you could overwrite
> arbitrary variables with arbitrary values anyway (again speaking of the
> one-argument version).  so you may be right that this is moot.
> 
> thinking as i go here, i guess the vector is that perhaps an app
> would sanitize the input by removing all but certain specified 
> variables, and then one of these variables triggers register_globals,
> which lets in everything else and clobbers the scope of thought to
> be safe variables.

Er...  If I write broken code, I must not wonder why the resulting
program is broken as well.  I'm sorry.  We cannot fix stupidity.

> > These don't warrant a security update since this function is only
> > used for debugging.  Whoever uses it as a regular feature of a
> > web application has other severe peoblems.
> <snip phpinfo() CVE's>
> 
> i think some applications have this information available under
> an "admin configuration" section.  but really, the issue is that
> info.php files are found scattered like litter all over the net
> as people often put them up to test one thing or another.  like,
> uh, http://people.debian.org/~seanius/security/php/poc/info.php.
> 
> eheh.

Err...  See above.  We don't "fix" the echo or printf functions either
just because they're not XSS safe.  See this POC for example:

http://host/foo.php?foo=<addevilscripthere>

<? echo $foo ?>

That's broken code, not something we *ought* to "fix" in the library
but in the application.  If Debian ships an application that has a
phpinfo() page publically visible, I'm happy to fix this application.
Well, no, I wouldn't be happy, I would swear like a trooper.

> > How is this triggered ans what's the outcome?  If it is triggered
> > by malicious input from remote that can control which parts of
> > memory is disclosed, it may be discussable.  If it is due to a
> > "wrong" use of the function in the PHP code, then it doesn't
> > warrant a security update either.
> > 
> > > +    - CVE-2006-1490: Memory disclosure via html_entity_decode()
> 
> i don't know the various uses for html_entity_decode, but could imagine
> a situation where user input (like a forum post) was passed to
> html_entities() before being stored on-system to deal with different
> input charsets, and then when being displayed on a page was passed
> back through html_entity_decode.
> 
> looking at the referenced gentoo bug report at
> 
> 	http://bugs.gentoo.org/show_bug.cgi?id=127939
> 
> i think this is a problem, as the disclosed memory is equal to
> the size of the input.

Err.. yes, except that both htmlspecialchars() and htmlentities()
would "fix" the string already.  Again, this is broken programming
that triggers a problem.  Nothing for a security advisory.

> > This one is... No, we can't fix broken code.  The error messages
> > will only be displayed when the pages are broken anyway, which
> > should not the case with distributed web sites - and if the pages
> > are broken, there are other problems to worry about than XSS.
> > I'm reluctant to fix this in a DSA but consider it a normal bug.
> > 
> > (CVE says it's only a problem in 5.1.1, is that not true?)
> > 
> > > +    - CVE-2006-0208: XSS vulnerability with html_errors
> 
> i think the ultimate judge on this one is whether or not it
> would affect a default install on a sarge system.  it seems
> that display_errors is set to On, but html_errors is Off.  if
> we don't fix it here there could potentially be a php app
> that turns it on even when disabled in php.ini, but that
> might be worrying too much.

Again, this is a result of broken programming.  The applications
should neither cause errors nor set this to On when they're not in
development in which phase they may be broken, of course.

> however, before i continue further... i want to make note at least
> once that several other distributions have decided that many of these
> "questionable" issues merited security updates/advisories.  they probably
> would not have released them as updates on their own, but since there
> were other unrelated vulnerabilities worth updating they included them.

Yes, some distributions jumped the gun (jumped on the wagon?  Whatever
the idiom is in English), but that does not make bugs security bugs.

Feel free to ask the SRM team if they are happy with a PHP update.

> > The description of this one looks like it's a real problem
> > that may warrant a security update.
> > 
> > If only a sufficiently long input string is required to trigger
> > the integer overflow and consecutively cause a buffer overflow
> > (more or less) regardless of the breakstring, it does.
> > 
> > (CVE says it's only a problem in 4.4.2 for 4.x, is that not true?)
> > 
> > > +    - CVE-2006-1990: Integer overflow in wordwrap()
> 
> i have a PoC that verifies it's a problem for sarge at the p.d.o directory
> mentioned earlier.

Err...  Yes:

<?php

$a = str_repeat ("A",438013);
$b = str_repeat ("B",951140);
wordwrap ($a,0,$b,0);

?>

Who the hell would do *this*?  Honestly!  Reality check!

If the programmer wants to exploit the running system, they should
just call popen or system or whatever they like.  There are hundreds
of ways.

If this requires a non-standard break string, then it is not remotely
triggerable without a dimwit doing the PHP programming.

> > This may actually warrant an update, bug probably not.
> > Who could exploit this?  Somebody who is allowed to upload
> > jpeg files.  Who would that be?  The owner of a web gallery
> > perhaps?  That guy has access to the PHP code and can run
> > a DOS in two hundred easier ways.
> > 
> > > +    - CVE-2005-3353: Possible DoS via malformed jpegs in exif_read_data()
> 
> this one definitely does all by itself.  apart from the hypothetical
> gallery admin being tricked into uploading something, you also have
> wikis, forums, etc which allow submissions from a larger group of
> potentially unauthenticated/unfriendly people.  the guy who originally
> reported it in the php bts was one of the wikimedia developers iirc.
> also, the offending image in his post (and the one sitting in my poc
> directory) was not a maliciously crafted image either.

I agree that this seems to warrant a security update.

Ok, so we're down to one vulnerability that may require fixing.

Could you provide a patch with only this one?

Regards,

	Joey

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.