Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29590
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: <4651356D.6010009@hardened-php.net>
Date: Mon, 21 May 2007 08:00:13 +0200
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: PHP internals <internals@lists.php.net>
References: <465022BE.1020905@hardened-php.net> <46510370.4050409@lerdorf.com>
In-Reply-To: <46510370.4050409@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Dismantling the lies...
From: sesser@hardened-php.net (Stefan Esser)


> You make things sound very black and white when they are usually grey.
>   
You only don't realise how black things are.

> this is an acceptable performance tradeoff.  We have to balance the
> seriousness of the vulnerability against the performance cost of the
>   
Yeah well. Luckily since Suhosin-Patch exists, people have a choice. And
they choose Security
(Suhosin) over performance. And sorry a tradeofff between performance
and security is never
a choice, when we are speaking about a simple compare operation.
You also did not even implement a simple compare per variable ptr dtor
that checks if the
refcount was already 0 on entry. This is not a 100% solution but it
catches a bunch of attacks
and it even catches the demonstration exploit for MOPB-1.
The choice of the PHP development team is to do NOTHING. And I am just
reporting about
this to make people aware. I know this is taken as attack from the PHP
development team, but
I am just reporting FACTS.
> 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.
>   
Considering the fact that the reference counter overflow was for example
triggerable through
unserialize() which made for example every phpBB Forum and every
serendipity vulnerable
to remote compromise. (An exploit exists in metasploit), makes your
statemt look rather
DUMB. Unfortunately I had to fix the symptom instead of the cause
because I was forbidden
to fix it correctly in PHP. The refcount overflow is therefore still a
ticking timebomb until someone
finds another way to trigger it remotely. This behaviour of PHP.net is
by the way the real reason
why Suhosin/HPHP exists: You only think in short terms, you don't plan
in the long run and
realise that fixing only symptoms solves no problems.

And well, I am obviously not the only one that believes the thing has to
be fixed, as the patch
by SuSE prooves. But well it is YOUR choice to ignore my warnings. But
then just ignore it
and don't resort to attacks like Stanislav and his php-shrink. Stop
complaining that I would not
help, because this is simply a lie. As a security researcher my job is
to point out bugs, not to fix
them. And if I do so (like I do so often f.e. in Suhosin), it is my
choice to do this outside of PHP.
And PHP.net has absolutely NO RIGHT to demand that I fix something. I
have no problem with
this anyway because your lack of compliance just drives more people into
the arms of Suhosin.
Which seems to be something you don't understand.

> 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.
>   
Uhm... I pretty much said the opposite. Moving to a 32-bit refcount does
not fix anything. It just makes
the bug not triggerable on 32 big platforms, because the memory required
would exceed the 32 bit
addresspace. On 64 bit systems things would be different again... (Again
a fixing symptoms approach)

PS: You should also think about stopping to claim that current PHP is
free of security bugs, when you
mean CVS. Current PHP is not CVS but the latest release. (And don't tell
me that it is not you who
claim it, but Stanislav. If you think otherwise you can correct him
anytime.)

Stefan