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

I want to see someone claim again

[suv4x4]

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

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]

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.

Right. PHP's the fastest language out there, as proven in this test.

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

[digidave]

The raw speed of PHP isn't very relevant. It's a language for low to mid-range web apps that is flexible enough to do high-end web apps as well. If your PHP app is slow it's probably due to poor programming or poor database indexing or design. PHP usually takes request data, gathers a database result, shuffles around some data, then displays an HTML page. It's easily fast enough for its purpose.

There are plenty of good criticisms for PHP (and every other language), but performance is only a factor in PHP web apps when the programmers do really stupid things.

Re:I want to see someone claim again

[Dragonslicer]

I can't speak specifically about performance problems, since I know pretty much nothing about the engine itself, but anyone that doesn't think PHP has consistency issues doesn't use the language enough. There's some pretty serious inconsistency in function naming, though that's pretty much limited to functions that have been in the language for several major versions (array and string functions especially). PHP5 is a huge improvement over older versions, but it would still be nice to be able to completely get rid of all of the mistakes that were made in PHP3. And yes, I do write PHP code professionally, and I think it's a very good language, but you'd have to be delusional or inexperienced not to recognize its problems. Every language has its positives and negatives.

Re:I want to see someone claim again

[omeomi]

Oh, you just mean naming conventions are inconsistent? I thought you were saying that, for instance, code written in one version of PHP doesn't work in a later version. That's a problem I haven't had. Upgrades have generally been pretty painless for me. And I've found PHP performance to be pretty good. My primary comparisons are with Perl and ColdFusion though, so maybe ASP is a lot quicker, and I just don't know it...

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:I want to see someone claim again

[CopaceticOpus]

This is where we need to draw a line when talking about how good PHP's security is. For the case of a PHP developer running his own trusted code on a server, PHP can be very secure if the code is well written. That's the developer perspective. The other case is the PHP hosting company or system admin, running other people's untrusted code. In that case, the situation is much trickier. It may be possible to host that code securely, but it will take a lot of work and paying attention to security notices.

So how worried you should be about PHP security comes down to whether you'll be running your own code you trust, or hosting someone else's code you don't trust.

Re:I want to see someone claim again

[RzUpAnmsCwrds]

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.

Right. PHP's the fastest language out there, as proven in this test.

You're comparing two completely differnet language types. You might as well compare Java and C++.

Compared to other interpreted (e.g. parse tree is built on the fly rather than by a compiler) languages like Python or Ruby, PHP is about average.

Compare PHP to the CLR (or Mono) or to the JRE, and PHP is going to be way slower.

But calling PHP slow because of some benchmark is just bull. Yes, Java or .NET is faster, and if you're writing an application that does a lot of crunching, by all means you should use a platform that is good at it. There are plenty of good reasons to choose J2EE or ASP.NET over PHP, but performance just isn't one of them in a lot of applications.

The Wikimedia Foundation runs Wikipedia (the 10th most popular website in the world) with PHP and 123 commodity PC servers. What does that prove? It proves that application design and system architecture is FAR more important than what platform you choose. You can run benchmarks all day long, but that doesn't change the fact that Wikipedia does far more with far less than most websites out there - and they do it with PHP.

I serve over 10 million pageviews a month on WS Network using PHP, MySQL, and a virtual server with 50MB of memory, a fraction of a 2.4GHz P4, and 100MB of swap. My informal load testing indicates that I could handle as many as 30 pageviews per second (80 million per month) with my current hardware and DB setup.

Maybe I could do more with J2EE or ASP.NET (or, perhaps I could do far less - ASP.NET and J2EE aren't as easy on memory as PHP for small apps). But the fact is that I am doing a hell of a lot already considering the very limited hardware I'm running on.

PHP code execution performance is not, and has never been, a major issue in my experience. It's the same way with Python, Perl, Ruby, and any other "scripting" language. The fact is, you're not going to write an H.264 codec or a PS3 game in Python. But many, many applications are not constrained by CPU performance. 8-core servers are now cheap. 16-core servers will be soon. Changing your language might give you 10x better performance. But architecture and algorithm improvements will probably get you much, much more.

"Performance isn't a problem until it's a problem."

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

Re:I want to see someone claim again

[cheater512]

In fact, IIRC Mono doesn't even support working as CGI, Uhh...Anything can run as CGI as long as it can be executed.

Heck you can make a bash script output your website for you. Or even QBASIC.

Bad release practices

[daeg]

I no longer use PHP, but these two releases highlight one of the things I hated the most about PHP. Every release, even minor "bugfix" releases (5.2.1 to 5.2.2) always do more than fix security and blocker bugs. That means that even if you're only updating to fix the mail() function, you have to run your entire site/system through testing to ensure the update didn't mysteriously break something else.

See, for example, the 4.6.6 release notes:

The PHP development team would like to announce the immediate availability of PHP 4.4.6. This release addresses a crash problem with the session extension when register_globals is turned on that was introduced in PHP 4.4.5. This release comes also with the new version 7.0 of PCRE and it addresses a number of minor bugs. That means that 4.4.5 introduced a major crash problem in a module every PHP website uses. How does that get missed? Also, why does that release also simultaneously bundle a new library version AND fix other "minor bugs"? Release the crash fix and that's it! Keep new features/minor bug fixes to point releases (4.5), not minor point versions.

Thank god Python doesn't do that. At least they keep all the big changes to individual versions!

Re:Bad release practices

[Ambush Commander]

What you're missing is that fact that PHP uses the three digit version numbering system to mean something slightly different than what you're used to. Increments in the 0.x.0 number indicate, besides major changes in the language, that extension compatibility was broken and thus they need to be recompiled (to see a great example of this, check PHP 4.4). 0.0.x releases do contain feature releases, but you don't have to worry about extensions breaking.

Firefox does the same thing too, except they end up stepping on extension authors feet when they increment the third version number! That's why they introduced a fourth number 0.0.0.x for memory leak / security fixes. But Firefox has the luxury of an auto-update system: something PHP doesn't have. It is in both sysadmin's and PHP's developer's best interests to not be releasing new versions every other week.

Re:Bad release practices

[Dragonslicer]

Yeah, I hate to admit it, but release management hasn't been the PHP developers' strength lately. I think 5.1.0 might have been the biggest screwup, where, after I think 7 release candidates, somebody committed new code a few days before the final release that created a builtin class named 'Date'. The thousands of people that used the PEAR class named 'Date' weren't too happy. In an amusing twist of irony, the developer that committed the code was a staunch opponent of adding namespaces to PHP.

Re:Bad release practices

[daeg]

As a good start, i recommend Django. It's a nice framework that takes care of a lot for you, but still lets you write Python. They have a few tutorials as well as a good community and an ongoing project, The Django Book. I transitioned directly from PHP to Python without any books. Most coding forms transition directly over to Python. As you learn more Python, you'll find shortcuts, e.g., the list constructs and lambda functions.

I also recommend reading over PEP 0008, the "standard" coding structure for the Python core libraries. It may seem restrictive limiting yourself to 79 character columns, but you get used to being able to read your code very quickly, especially if you come from PHP or Perl. (Tip: USE SPACES FROM THE START! You'll thank me later.) I can't underestimate the awesomeness of the interactive Python shell, either, especially for beginners.

There are also other platforms out there, Turbogears and Pylons being two notable ones. I think the Django documentation is a bit better, though.

You may also look up Web.py, which is as close to "drop and run" PHP as you'll get without going to pure CGI.

Python takes a little more care to set up at the server level, and you won't find may $1 hosts that support it.

Most of these bugs are completely preventable

[chatgris]

There is really no excuse for those memory bugs. There are free, simple tools that check C code and memory management (and php itself is written in C).

"double freed memory to bugs in functions that allow attackers to enable register_globals, to memory corruption with unserialize()"

The authors of php should use valgrind, and with a few test cases, could virtually eliminate memory errors.

Memory errors have been around for so long that there are numerous tools for dealing with them, many of them free. I know that many people on slashdot like to put down the importance of an education, but the knowledge, ability and discipline to use these tools is what separates professional software engineers from (generally smart) people who just hack at things.

Re:You must be mistaken.

[MrMunkey]

I'm not sure if you had some /sarcasm there or not. I'll assume not and say that you're partly right.

I'm a PHP developer. I love PHP because I haven't come across anything that I can not do with it yet. Does that mean it's the best programming language ZOMG 3V3R! No. PHP is a pretty good general purpose web scripting language. Like all the other languages out there, it has bugs or features that haven't been implemented or thought of yet, and that's why there are version numbers.

PHP does suffer some of the same issues that C++ has suffered in the past, and they are due to the fundamental ideas of the project. PHP doesn't have a framework for you to do everything. I guess that mostly comes up with ASP and probably Ruby, but I'm a little under read on Ruby. Much like the C++ vs. Java debate, C++ makes you do things yourself (or at least you need to know about the community projects that make life easier... like smart pointers and the like). That's pretty much the same with PHP. You have the base functions, and there are extensions you can get to help, but MVC and other parts of frameworks are left for you to decide what you want or need for your project.

So, with that in mind, security is also left up to the developer. PHP 5.2.x has made a lot of great strides in helping out by introducing the Filter extension and others. If people do not filter/escape the input/output from their pages, they're just opening up a can of worms. I'm a firm believer in saying it's easier to filter yourself than undo a filter that the system did for you automatically.

PHP has its issues, but I don't think it would be as popular as it is if PHP didn't serve a purpose and do it somewhat well.

Examples of PHP inconsistency and performance

[Snover]

Sure, I'll give you some.

Inconsistent function naming (underscores):

substr_compare() vs.
strcmp()

More inconsistent function naming (verb location):

file_get_contents() vs.
get_html_translation_table()

Even within the same extension:

imagesetstyle() vs.
imagecolorset()

Flipped haystack and needle:

strpos(haystack, needle) vs.
in_array(needle, haystack)

Speed:

Scutigena Computer Language Performance Comparison (see graphs)
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. I can't seem to find it now, though. Also PHP5 might compare a bit more favourably, but this is all I could find after a quick Google search. Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.

I think PHP is overall a fairly decent language; I've used it for many years with great success. But it does have major problems, and it would be nice for them to get fixed instead of pushed aside. (I read some minutes from a PHP 6 meeting a while ago where they touched on the issue of consistency, and the PHP Group decided that it wasn't important enough to fix. It's really annoying to me to need a PHP-aware IDE or a manual always handy to program in a language because the arguments and function names are so non-uniform.)

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>

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.

Re:Examples of PHP inconsistency and performance

[jsebrech]

Perhaps more importantly, PHP drags the speed of other things down (like Apache), since even though the core is supposedly thread-safe, nobody seems to know which extensions are and aren't, so eg. Apache needs to be run in prefork mpm instead of using a threaded mpm.

This is my main beef with PHP. They have their head in the sand with regards to server configuration.

Case in point: the company I work for sells PHP-based service center and reservations systems to large companies. These companies generally have windows-based server infrastructures, so we have to deploy on windows/IIS. If you look at the suggested configuration for PHP on IIS in the PHP manual, you'll find this page, which explains regular CGI and ISAPI (multi-threaded) configurations. What the manual doesn't tell you is that neither of these configurations actually work in production environments. Regular CGI configurations are too slow (on windows), and ISAPI is too unreliable (customers that deployed with ISAPI configurations suffered daily server hangs).

The only viable configuration for production IIS servers, as it turns out, is FastCGI, which is not documented in PHP's manual section on IIS configuration. Their documentation actively misinforms people on how to configure PHP. That's bad.

Re:seriously ...

[VGPowerlord]

PHP is just some hyped, misdesigned, inconsistent, unproductive kinda tool.

Unfortunately, mod_php is still more programmer and administrator friendly than mod_perl, which probably explains why it has a higher usage rate.

Re:yeah yeah yeah

[CopaceticOpus]

PHP is getting better. They are cleaning up security issues, and providing more and more of a solid core of capabilities. I just wish that the users were more excited about these developments. I can't understand why so many continue to develop in PHP4. Every change and step forward gets a mixed response.

Personally, I'm all for breaking conventions if it will result in making PHP a better language. I wish that they would bite the bullet and rename all the functions to follow a consistent style in PHP6. Those who can't handle it can stick with 4 or 5, but let's look to the future and make PHP the best it can be.

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:You must be mistaken.

[Jasin Natael]

For multi-threading, install a shared-memory cache, like apc, eAccelerator, or mmcache -- or use an in-memory table in your RDBMS. Now, you can spawn background tasks and monitor their progress or receive return values through the cache. You can even start a task as a server and keep it running indefinitely with set_time_limit(). I do plenty of unicode apps as UTF-8, and haven't had problems yet. If you're talking about UCS-2, then you have a good case. It's in development, but it's for PHP 6. Honestly, I'll probably switch languages before v6, based on all the other crap they're talking about throwing in. Version 5 is already getting pretty bloated, and it's only marginally faster than Java.

Here's the utility function I use to spawn background threads (like, sending a thousand customized newsletters or updating hundreds of thousands of database rows). The background process can either lock a file or create some shared-memory structure to indicate its progress, and you can return immediately and end the script before it's done running. The nice prefix is optional.

function fork($shellCmd) {
exec("nice $shellCmd > /dev/null 2>&1 &");
}