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."

Re:I want to see someone claim again

[KidSock]

I want to see someone claim that the "month of bugs" projects harms the products involved. From what we saw with Apple and PHP, they finally closed holes gaping for many previous versions.

Now if only could PHP also fix their performance and inconsistencies..

There's nothing "gaping". All the "month of bugs" were non-critical stuff pumped up by Esser for whatever reason I don't know. 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.

At first I thought you were trolling but from your "fix their performance" statement I realize you just don't know what the hell you're talking about.

I'm happy to see bugs fixed but actually, I'm going to hold off on updating. These sorts of releases have a tendency to break things. Of course it might not but AFAIK these releases don't fix anything remotely exploitable so you won't see me running for the nearest terminal.

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.

Re:Examples of PHP inconsistency and performance

[Renegade88]

There used to be another site that you could compare one language's speed relative to another that also showed PHP as one of the slowest.

Yep, there still is. I think you are thinking about this one:
Computer Language Benchmarks Game [debian.org]>

That site features 19 programs implemented in 33 languages. Each program stresses something. You can see relative execution times and memory use, and it lets you pit one specific language and another and see how they compare.

Yes, PHP loses in pretty much every performance category against compiled languages and even C#/mono.

Comparing mono with C# is unfair

[anss123]

Mono is a byte compiled language, not interpreted. Even so, PHP is still beaten quite badly by Perl. (In those benchmarks)

Re:I want to see someone claim again

[shish]

The Wikimedia Foundation runs Wikipedia (the 10th most popular website in the world) with PHP and 123 commodity PC servers. What does that prove?

Throwing more hardware at a problem will solve anything \o/

I'm running a service which was originally PHP on a throwout box in the corner of my bedroom -- after a few months, the service was so popular the box was in a state of slashdottedness 24/7. I then moved to a shared host, where it ran happily for about a year, until it got so big it started breaking their uber-servers too. I have now rewritten it in python, and moved back to hosting it myself :P