Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29585
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <46510370.4050409@lerdorf.com>
Date: Mon, 21 May 2007 10:26:56 +0800
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Stefan Esser <sesser@hardened-php.net>
CC: PHP internals <internals@lists.php.net>
References: <465022BE.1020905@hardened-php.net>
In-Reply-To: <465022BE.1020905@hardened-php.net>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Dismantling the lies...
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Stefan Esser wrote:
> The reason for this fix not being applied is not it's impossibility, but
> because the
> closed source extension developers (everyone knows who they are) don't want
> another binary compatibility break, because then their closed source
> extensions
> have to be shipped in yet another version.

I don't have any commercial closed source extensions and am not
affiliated in any way with anyone who has some, and I'd rather not see a
PHP 4.5 just for this fix either.

> However there exists another fix to the problem that deals with the
> actual problem
> of an overflowing reference counter. Therefore every refcount increase
> in the Zend
> Engine Source has to be protected. While this sounds much of work it
> actually takes
> less than half an hour to do it.
> 
> Here is the patch I created in approximately half an hour. A solution to
> a problem
> that is *NOT* fixable at the moment, according to Stanislav.

You make things sound very black and white when they are usually grey.
In this case the main objection to this rather obvious fix has always
been performance.  Adding a check on every refcount increase is a bit
scary for the performance folks.  It may be that in most realworld cases
this is an acceptable performance tradeoff.  We have to balance the
seriousness of the vulnerability against the performance cost of the
fix.  The thinking on this one has been that the actual vulnerability is
rather obscure, which I know you don't agree with, but that's been the
driving factor which makes it hard to justify any performance tradeoff
to fix it.

As you said, moving to a 32-bit refcount is a better fix which is why we
chose to go that route and encourage people who feel this is not an
obscure vulnerability in their environment to migrate to PHP 5.

-Rasmus