Slashdot Mirror
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 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..
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!
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.
Open Your Mind. Open Your Source.
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.
Unfortunately, mod_php is still more programmer and administrator friendly than mod_perl, which probably explains why it has a higher usage rate.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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.
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.
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.