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