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

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

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 [php.net]:

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

[gnud]

[snip]This release addresses a crash problem with the session extension when register_globals is turned on that was introduced in PHP 4.4.5.[snip](emphasis mine)

If you use register_globals, you deserve all bugs that hit you. Period.

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.

Re:I want to see someone claim again

[suv4x4]

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.

What you're saying: PHP is only good for gluing your DB to your HTML, straight procedural code. But that was true in the distant (in IT terms) past of the web, before PHP programmers got educated enough to demand applications with proper architecture and provisions, manageable and stable code, versus the spaghetti code we see so often in old open source PHP projects.

Plus, go teach Zend about your view on their language. Their framework has terrible speed on their own language. Stupid Zend, doing stupid things.

You can't put randomly a line where something becomes "too complex for PHP" and where it's not. If PHP struggles for tasks fast enough for other comparable, means the problem isn't in the programmers. In the end PHP loses, by having an "elite" of folks who would rather stubbornly defend PHP's faults than do something about them.

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:lipstick on a pig...

[Anonymous Coward]

you -are- a troll. I can write C programs just as insecurely as I can in PHP. If you are careful and have goood programming practices, you won't be affected by many of the 'holes'. The only problem is, the bar for entry is pretty low for PHP and there are lots of people who just learned 10 a=a+1 : 20 print a : 30 goto 10 and php is their next big adventure.

If people like you were right, we'd all have ditched perl long ago because of the phf bug.

PHP, like any software has its holes, but a properly secured system isn't much more likely to be compromised than an IIS server.

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.

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 [php.net], 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: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.