Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29577
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hardened-php.net from 81.169.159.221 cause and error)
Message-ID: <465022BE.1020905@hardened-php.net>
Date: Sun, 20 May 2007 12:28:14 +0200
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Dismantling the lies...
From: sesser@hardened-php.net (Stefan Esser)

Hello,

it is no secret that I am really sick and tired of this constant stream
of nonsense and
lies comming out of the mouths of PHP developers when it comes to
security issues.

In the other thread, where Stanislav spreads the usual lie/propaganda that
there is no help comming from me to the PHP developers, he also claims
that the MOPB issues #1 and #2 cannot be fixed right now.

Xdebug, Suhosin, Hardening Patch have already demonstrated for years that
it is not true that #2 [2] cannot be fixed without breaking binary
compatibility.
There have also been patches on this mailinglist that calculated the maximum
depth automatically, therefore there is no need to dismantle this lie.

The other lie however that MOPB issue #1 [1]  is unfixable ends here...

First of all everyone into PHP development knows that the obvious "fix" for
this issue would be to just break binary compatibility and use a 32 bit
reference
counter. It does not fix the actual problem but it is enough so that it
cannot be
triggered anymore.

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.

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.

http://www.hardened-php.net/patches/php-4.4.7-refcount-overflow-fix.patch.gz
MD5: 0b558564d86b798651b69181920f9378
 
Stefan Esser


Reference:
    [1] - reference counter overflow -
http://www.php-security.org/MOPB/MOPB-01-2007.html
    [2] - deep recursion crash -
http://www.php-security.org/MOPB/MOPB-02-2007.html