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

[sean finney]

hey joey,

On Mon, 2006-09-18 at 17:02 +0200, Martin Schulze wrote:
> sean finney wrote:
> > > =================================================
> > > 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

> It's still a non-issue unless somebody explains to me which regular sane
> PHP script contains code like
> 
> $object_zval = $eip_hop_over.$ptr_to_obj_handlers.$eip_hop_over.
>                "\x05\x01\x90\x90".$shellcode."\xC3\x90\x90\x20";

okay, so unless i hear otherwise i'll take this one as a non-issue.

> > > =================================================
> > > 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?
> 
> I'm a bit in trouble here, since I don't understand the attack vector.
> 
> The description reads:
> 
>    PHP before 4.4.3 and 5.x before 5.1.4 does not limit the character
>    set of the session identifier (PHPSESSID) for third party session
>    handlers, which might make it easier for remote attackers to
>    exploit other vulnerabilities by inserting PHP code into the
>    PHPSESSID, which is stored in the session file. NOTE: it could be
>    argued that this not a vulnerability in PHP itself, rather a design
>    limitation that enables certain attacks against session handlers
>    that do not account for this limitation.
> 
> Even if I provide a PHPSESSID that contains PHP script code how could
> this be evaluated as PHP?  The ID is used as a lookup keyword in the
> list of stored sessions (i.e. represent a filename).

LABEL: 4433

it seems kind of sketchy.  given that there haven't been any real world
attack vectors, plus the fact that's it's probably an application issue,
i vote we skip it unless someone has a compelling argument otherwise.


> > > =================================================
> > > 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*.)
> 
> This may indeed a real issue that should be fixed.

i'll do so and provide an updated package.

> > > =================================================
> > > 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.
> 
> Then it's indeed a different vulnerability in GD and xloadimage/xli.

yes, that's my impression.  sf opened bugs against the two packages in
the meantime.

> > 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?
> 
> non-issue
> 
> > - CVE-2006-4433(sessions): fix or not?
> 
> <nr5>

goto 4433;

> > 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)
> 
> How public are they?  I.e. do we need to go through MITRE?

it seems that nobody else has bothered to notice this, including the php
folks who ship a bundled version of the vulnerable library.  however as
i mentioned sf has published bug reports on it.  since it's a heap-based
vulnerability, and there doesn't seem to be anything useful to
overwrite, i don't think it's a horribly critical issue.  then again, i
could have missed something somewhere.


	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/20060919/fe554b05/attachment-0001.pgp