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

[Martin Schulze]

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

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";

If a malicious PHP script is required to exploit the vulnerability, then
it's a non-issue since there are uncountable ways to exploit php and
break out of the so called safe_mode - and without that there are more
ways to get access to the system PHP is running on without the need
for an exploit.

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

Yep, 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).

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

Ack.

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

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

Ack.

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

> > =================================================
> > 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?

That's what MITRE/Steven writes when he has no details either.

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

> - CVE-2006-4482(new wordwrap): fix or not?

Fix.

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

Regards,

	Joey

-- 
There are lies, statistics and benchmarks.