PHP 5.2.2 and 4.4.7 Released

daeg writes "PHP 5.2.2 and 4.4.7 have been released with a plethora of security updates. Many of the security notifications come from the Month of PHP Bugs effort, and range from double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize(), to input validation flaws that allow e-mail header injections, with an unhealthy sprinkling of other bugs and flaws fixed. All administrators that run any version of PHP are encouraged to update immediately."

Comments

Re:I want to see someone claim again

[suv4x4]

In PHP's defense, how does performance compare once some sort of accelerator is involved? Are those fancy output caching engines or do they actually precompile/cache the code or something like that?

When you run a PHP file, there are two stages of execution:
[build a parse tree from the source and output bytecodes] [interpret the bytecodes]

The accelerators cache the bytecodes, so next time they are loaded (usually from RAM) and interpreted directly.

However compare with what you get with the CLR by default:
[a compiler builds the parse tree and outputs bytecodes] [opcodes are compiled to machine code] [natively run machine code linked to a runtime library]

You basically never ever repeat the first step more than once there, and in some cases the second. And running as native code is hella faster. A big problem with PHP is it abuses string hashes and fails to do early binding where appropriate (indexed serial arrays, class objects and methods etc.).

So everything you reference in PHP requires a bunch of hash lookups. It's terrible.

Re:I want to see someone claim again

[arodland]

For example, there were a number of bugs that required the attacker to be able to supply their own code. If the attacker can supply their own code, they can just call popen() or system() and dispense with all the hoopla required to compermise the worker and inject shellcode. Well actually... no.

PHP enjoys overwhelming popularity in shared-hosting environments, where you put a lot of users on one server, and the users supply the code, but you don't really trust the users. You don't want them to compromise other users' reliability, or break your server, or do anything very interesting... but you still have to let them run their code because that's what the service is. So PHP comes with all sorts of features to facilitate this... "safe mode" and the like. But if there are security issues all through PHP that poke holes in this security model, then you find yourself in a microsoft-esque situation where the security isn't real at all, and you're screwed. Not so pleasant.