[php-maint] Re: research for recent PHP security vulnerabilities

[sean finney]

hey martin,

On Thu, 2006-09-07 at 14:25 +0200, Martin Pitt wrote:
> I just finished the PHP security update for Ubuntu, to fix some of the
> recent issues. I talked to Sean yesterday and promised to share my
> patch research, so here it is.

i'll put comments inline, as i've discussed some of these with the
security team already.  i'm going to add in a few addresses in the
cc field to make sure everyone's on the same page if you don't mind.

> =================================================
> CVE-2006-4020
> sscanf buffer overflow
> http://bugs.php.net/bug.php?id=38322
> 5.1: http://cvs.php.net/viewvc.cgi/php-src/ext/standard/scanf.c?r1=1.31.2.2&r2=1.31.2.3
> 4.4: http://cvs.php.net/viewvc.cgi/php-src/ext/standard/scanf.c?r1=1.16.4.9.2.1&r2=1.16.4.9.2.2
> 
> The sscanf() function did not properly check array boundaries. In
> applications which use sscanf() with argument swapping, a remote attacker
> could potentially exploit this to crash the affected web application
> or even execute arbitrary code with the application's privileges.

i think this is one joey and moritz disagreed wrt whether it is a
problem worth an update.  the impression i got from joey was that this
is a bug, but it's not a security issue since it would require
deliberate coding in the application, and wouldn't achieve anything
beyond what one could do deliberately otherwise.  but iirc moritz
believes otherwise?

> =================================================
> CVE-2006-4023
> ip2long() information disclosure
> no patch yet

i don't think we're going to bother fixing this one, because the
"information disclosure" just means that ip2long can be tricked
into falsly processing things that aren't ip addresses.  the php
manual states that other steps should be taken to validate that
the input is a valid ip address.

> =================================================
> CVE-2006-4433
> does not limit the character set of PHPSESSID
> a bit diffuse and questionable, bug in Zend core, needs further investigations

gut feeling is that joey will say this does not warrant a security
update, since it would be a problem with the session handlers /
applications that don't do the checking.  or.... joey?

> =================================================
> CVE-2006-4481
> safe_mode/open_basedir bypass with file_exists() and imap_reopen()
> 4.4 [imap_reopen()]: http://cvs.php.net/viewvc.cgi/php-src/ext/imap/php_imap.c?r1=1.142.2.44.2.5&r2=1.142.2.44.2.6
> 5.1 [imap_reopen()]: http://cvs.php.net/viewvc.cgi/php-src/ext/imap/php_imap.c?r1=1.208.2.8&r2=1.208.2.9
> 5.1 [file_exists()]: http://cvs.php.net/viewvc.cgi/php-src/ext/standard/filestat.c?r1=1.136.2.8&r2=1.136.2.9
> 
> The file_exists() and imap_reopen() functions did not perform
> proper open_basedir and safe_mode checks which could allow local
> scripts to bypass intended restrictions.

we'll definitely be skipping this one.

> =================================================
> CVE-2006-4482
> str_repeat() and wordwrap() buffer overflow on 64 bit systems
> 5.1: http://cvs.php.net/viewvc.cgi/php-src/ext/standard/string.c?r1=1.445.2.14.2.10&r2=1.445.2.14.2.11
> 
> On 64 bit systems the str_repeat() and wordwrap() functions did not
> properly check buffer boundaries. Depending on the application, this
> could potentially be exploited to execute arbitrary code with the
> applications' privileges. This only affects the amd64 and sparc
> platforms.

this is different from the other wordwrap problem which we decided not
to fix.  i'll have to doublecheck the problem, but i think this one
doesn't require the programmer to be a total dimwit like the last one.
(for reference, the last one required using a ridiculously long
"seperator" expression, where this one could be leveraged by arbitrarily
long text and normal seperator expressions, i *think*.)

> =================================================
> CVE-2006-4483
> safe_mode/open_basedir bypass with curl
> (already fixed as CVE-2006-2563, the actual CVE-2006-2563 fix might be
> a different one)

skipping this one too.

> =================================================
> CVE-2006-4484
> GIF parser overflow
> 4.4: http://cvs.php.net/viewvc.cgi/php-src/ext/gd/libgd/gd_gif_in.c?r1=1.2.2.2.6.2&r2=1.2.2.2.6.3
> 5.1: http://cvs.php.net/viewvc.cgi/php-src/ext/gd/libgd/gd_gif_in.c?r1=1.5.4.4&r2=1.5.4.5
> 
> A buffer overflow was discovered in the LWZReadByte_() function of the
> GIF image file parser. By tricking a PHP application into processing a
> specially crafted GIF image, a remote attacker could exploit this to
> execute arbitrary code with the application's privileges.

fyi: stefan fristch and i worked on this one, and it's a non-issue
*for-php*, at least in debian.  unless ubuntu does things differently,
php is not compiled against its own bundled libgd, but instead the
libgd2-dev, which is where the real problem is.  therefore, this also
affects any other libgd2-using package.

also, while looking into this we discovered that xloadimage is
vulnerable (even though it shares no code) to the same corrupt
gif, but these really ought to be two seperate vulns.

i have info about this up at

http://people.debian.org/~seanius/security/php

look in the PoC section for 38112.{gif,poc}, which i did before a CVE
was issued on it.

> =================================================
> CVE-2006-4485
> stripos() overflow
> 4.4: N/A (function does not exist)
> 5.1: mentioned in release announcement, but not in detailled changelog, no CVS fix

fortunately sarge doesn't have php5, so we'll just let the latest
upstream version fix it in etch/sid and forget we ever saw it :)

> =================================================
> CVE-2006-4486
> unspecified memory_limit bug on 64 bit systems
> further information required

..."Unspecified vulnerability in PHP before 5.1.6, when running on a
64-bit system, has unknown impact and attack vectors related to the
memory_limit restriction."...

wtf?  unspecified vulnerability with unknown impact and attack vectors?
who's the clown giving these things out?


joey/moritz:  i think at this point to get a cumulative release for
stable, we'll need an authoritive statement on the following:
- CVE-2006-4020(scanf): fix or not?
- CVE-2006-4433(sessions): fix or not?
- CVE-2006-4482(new wordwrap): fix or not?

additionally, we should:
- get 2 new CVE numbers for libgd and xloadimage respectively.
- fix the problem in xloadimage (the php patch fixes libgd2,
  but xloadimage has no common code and it was just luck that
  i stumbled across this)

anyway, thanks for taking the time to collect all this info!


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20060907/14dbb728/attachment.pgp