Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27944
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain redhat.com designates 66.187.233.31 as permitted sender)
Date: Fri, 9 Feb 2007 15:41:55 +0000
To: internals@lists.php.net
Message-ID: <20070209154155.GA16403@redhat.com>
Mail-Followup-To: internals@lists.php.net
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.4.2.1i
Subject: PHP 5.2.1 security issues
From: jorton@redhat.com (Joe Orton)

Hi, I'm looking through the list of security issues listed in the 5.2.1 
release notes; trying to work out what the impact of these issues is so 
we're able to explain to our users how they are affected.

Could anyone help clarify a few of the items listed?

- Fixed allocation bugs caused by attempts to allocate negative values 
in some code paths

I presume this refers only to the numerous emalloc->safe_emalloc 
changes, is that correct?

- Fixed unserialize() abuse on 64 bit systems with certain input strings

The only change to the unserializer in 5.2.1 that I can find was to add 
support for the "S:" token type; this doesn't seem security-related.  Is 
there something I missed here?  Was it a fix to the generated parser 
code rather than the grammar/sources?

- Fixed a possible buffer overflow inside mail() and ibase_{delete,add,modify}_user() functions.

The only change to mail() was:

http://cvs.php.net/viewvc.cgi/php-src/ext/standard/mail.c?r1=1.87.2.1.2.1&r2=1.87.2.1.2.2&diff_format=u

I can't see how the old code could present a security issue here.

There were no changes to the sqlite extension per se, but the change to 
the bundled copy of the sqlite library looks like like a buffer overrun 
fix:

http://cvs.php.net/viewvc.cgi/php-src/ext/sqlite/libsqlite/src/encode.c?r1=1.5.4.1&r2=1.5.4.1.2.1&diff_format=u

or am I missing something else?  (so, any user who configures using an 
external copy of sqlite2 would still be vulnerable to that issue)

Regards,

joe