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

sean finney seanius at debian.org
Tue Aug 15 21:52:54 UTC 2006


hey joey,

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.

php maintainers: comments would be very helpful here.

> 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.

i wouldn't say that any of the phpinfo() issues are more than low
risk, but if there's going to be a security update we might as
well include the fix since it is also fairly well-contained.

> 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.

> 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.

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.

> 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.

> 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.



	sean

(ps - putting pkg-php-maint back in the cc in the hopes that someone is
      actually reading it)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20060815/45d16f95/attachment.pgp


More information about the pkg-php-maint mailing list