> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
