Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27945
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 64.233.162.229 cause and error)
In-Reply-To: <20070209154155.GA16403@redhat.com>
References: <20070209154155.GA16403@redhat.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <DB698DDF-02A2-4D89-9BAC-7D4DB3BE79C0@prohost.org>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Fri, 9 Feb 2007 10:49:57 -0500
To: Joe Orton <jorton@redhat.com>
Subject: Re: [PHP-DEV] PHP 5.2.1 security issues
From: ilia@prohost.org (Ilia Alshanetsky)

Joe,

I am reluctant to disclose more information about the particulars of  
the issues so soon after the release, without giving a change for  
people to upgrade to it first. Once a month or so passes, I'd be  
happy to provide you, or anyone else interested with additional  
information about the specifics of the fixes. Although I suspect the  
MOPB planned by Stefan in March will identify most of the resolved  
issues with lots of detail.


On 9-Feb-07, at 10:41 AM, Joe Orton wrote:

> 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
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ilia Alshanetsky