The PHP development team would like to announce the immediate availability of PHP 5.3.5 and 5.2.17. This release resolves a critical issue, reported as PHP bug #53632 and CVE-2010-4645, where conversions from string to double might cause the PHP interpreter to hang on systems using x87 FPU registers. The problem is known to only affect x86 32-bit PHP processes, regardless of whether the system hosting PHP is 32-bit or 64-bit. You can test whether your system is affected by running this script from the command line.

All users are strongly encouraged to update their releases. While the problem only happens in certain circumstances, it can still be a huge problem since the data comes directly from the user. For more information about the issue see this post.

There has been several instances where people using WINCACHE have reported problem while running it on the actual production server. They have complained that WINCACHE works very well on development server but the users can see a crash (or different symptoms of it) while actually deploying it on a live production server.

There have been several reports of the issue where the site visitor gets an empty page back and WinCache will crash. For those wanting to get into the technical details, the post includes them or, if you just want to find out more about the bug, there's a few email addresses you can contact the WinCache team at.

I'm still bored and lacking posting ideas, so I figured I'd give a hyper-critical breakdown of "Four reasons to hate CakePHP" by A.J. Brown. Let's get right into it.

He responds to comments on: CakePHP's "heaviness", the (in)flexibility the framework allows, alpha releases, changes between versions, no namespace considerations and its use of global functions.

You can see the original post here: Four reasons to hate CakePHP as well as his AJ's own response to comments he recieved - Maybe I was too hard on CakePHP.

rPath has issued an update for multiple php packages. This fixes some vulnerabilities, where some have unknown impacts and others can be exploited by malicious, local users and malicious users to bypass certain security restrictions.

The original advisory has links to the updated versions and to references as to what has changed.

In its default configuration, rPath Linux 1 does not install php5 and is thus not vulnerable to these attacks; however, systems to which php5 has been added may be vulnerable to one or more of these attacks.

After investigating (which in my case meant briefly recalling from memory how PEAR actually validates dependencies), I remembered that PEAR validates dependencies twice, once prior to download, and once prior to installation. By the time the dependencies are sorted, PEAR assumes that the sort algorithm properly sorts things.

This is actually a pretty reasonable assumption considering the unit tests that are in place to test this. However, like all regression testing, the unit tests test boundaries and likely cases, but not all possible inputs.

So, to try to figure out where things might have gone wrong, Greg does a little research to find the problem. He discovers that it has to do with the order that the "subpackages" for the dependencies are installed, where the contents of those files are not removed correctly before installation, resulting in a file conflict.

Because there are meanwhile a lot of rumours about this vulnerability in the underground and because the PHP 4.4.3 release announcement does not mention this critical hole at all I wrote up a little article about it, which you can read here.

The article (from Hardened PHP) describes the issue - a problem in the hash tables of the Zend Engine, specifically the zend_hash_del_key_or_index function. The logic contained inside the function can find the wrong "bucket" of information and remove it. He also includes PHP code examples that show the issue in action.

To be protected, it's recommended to update to the latest versions of PHP that have been released - 4.4.3 and 5.1.4.