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!
I failed to include support for curl when 5.2.1 came out and just spent close to an hour waiting for PHP 5.2.1 to compile, yesterday. Guess it's time to run ./configure again.
True science means that when you re-evaluate the evidence, you re-evaluate your faith.
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.
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.)
[insert witty comment here]
yeah, PHP is sloppy, insecure by nature, and full of bugs - but there's a lot to be said for good programming practices as well, which when used can remedy many of these flaws. it's unfortunate that PHP is so easy to learn, as it has attracted hordes of people who couldn't or wouldn't learn another programming language, and of course, failed to learn (or have no desire to learn, hey it works just fine) anything about security, program efficiency, or how someone could take advantage of their sloppy coding. companies need web apps to be done yesterday, and they'll hire just about anyone based on a resume half the time, or find someone on one of those god awful freelancer sites. a lot of the time, "anyone" turns out to be some jackass who discovered PHP a few months ago, figured out how to connect to a database, and suddenly decided they were a programmer.
that said, PHP is useful and a good performer when the right hands and brain are doing the work. i would be reluctant to hire anyone who learned PHP as a first language and hasn't moved on to something else by now, regardless of their experience level. nearly any language used for developing web apps can be dangerous in the wrong hands, it's usually PHP these days because those people can't manage to learn another language (unless it's coldfusion, and that's a completely different disaster).
where i work, we use PHP. it's just everywhere; things are so easy to write that a lot of things have been written, and now someone has to either a) rewrite it all in another language, or b) just maintain and try to improve the existing codebase. guess what - "b" is the choice right now, and that's the way it is. i'll bet this is the case in a lot of places. i spend time trying to convince my superiors of PHP's shortcomings and the sensibilty of retiring some of this old junk in favor of something more robust and secure (like python), and they listen to me, but don't think that now is the time. i like where i work, and they do listen to me, so when it's time, i'll be there to do the work, the right way. if i wanted to leave, i'd definitely go somewhere where PHP wasn't used.
and don't say PHP isn't getting any better. 5 is much better than 4, at least for OOP, and from what i can tell 6 will be even better, getting rid of register_globals altogether will be a dream come true for me (even if it breaks tons of code - not mine though, that's for sure), possibly namespaces finally, and E_STRICT errors will be the norm.
What are you talking about? Read the summary, PHP has just fixed yet another batch of security holes. Trying to distract from the fact that PHP itself is poorly written and constantly full of exploitable holes is bull. Yes, lots of people write shitty PHP code. No, that does not mean PHP itself is secure, as their never-ending stream of security holes demonstrates.
Here's a link to Secunia's Tomcat 5 advisories, one of which is a remote code buffer overflow exploit.
http://secunia.com/product/3571/?task=advisories
So yes, while PHP's advisories are about 10 orders of magnatude more numerous than Tomcat's, it still "bug that would let a remote user execute code or change configuration settings or read files or doing a double-free or any of that kind of thing".
And trust me, it's just as easy to create fragile code in Java that can open your server like goatse as it is in any language, but it does seem to me that PHP puts most of the yoke of security squarely on the coder's shoulders. Unfortunately, I've also seen the code produced from those programmers, and the yoke was way too heavy for them to bear.
you obviously don't understand the PHP versioning.. this is like Microsoft updating XP and Vista... it doesn't mean upgrade to latest version of XP, then to latest version of vista... it means update your version.
insight through the mind
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
The buffer overflow you have referenced is in the mod_jk Apache module, written in C, which provides an AJP connector for communicating with Tomcat. It was not in the Tomcat application server.
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.
If you don't need total control over how Apache behaves, use mod_fastcgi not mod_perl. For fastcgi typically the webserver forks off the webapp as a separate _persistent_ process and then they talk to each other via a socket (you could actually have the webapp on a separate machine, but I haven't had much need to do that yet). Fastcgi apps can be coded similar to CGI/mod_perl apps there's just a loop around the "Fastcgi accept" call.
With fastcgi you can use perl, python, ruby, C++ or whatever - just like you can use these with CGI.
It may be _slightly_ slower - two processes talking to each other rather than one big process, but it is faster than CGI. And it's more robust and clean than mod_perl.
Also, if apache ever gets too slow, you can switch to Zeus, and you can still use fastcgi there. No change to your code.
Yea really? what about multi-threading and proper unicode support?
Mono is a byte compiled language, not interpreted. Even so, PHP is still beaten quite badly by Perl. (In those benchmarks)
I tested it last night on a Win2003 Server box, and there is a missing file from the Win32 ZIP distribution: php_xmlrpc.dll.
http://bugs.php.net/bug.php?id=41292
The file can be obtained from the latest snapshot, though: http://snaps.php.net/
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.
True science means that when you re-evaluate the evidence, you re-evaluate your faith.
You made good points about multi-threading, but it's possible the GP was also talking about multi-threaded support. It's a rumor that PHP itself isn't multi-threaded. Some of the older extensions are not multi-threaded, and that is why the suggestion to not go with multi-threaded apache exists.
Here's another issue I have with updating to the latest version of PHP. I'd venture to say that quite a few companies out there use RedHat, SuSE, or some other OS/distribution because they get support. If we upgrade to the newest version of PHP, we lose vendor support for it. That's not to say that I can't compile it, it's just that the company isn't willing to risk losing support.
ah i know well how to start a new process from command line (and do so in a php based sockets server) but if you ever did Comp Architecture 101 you would realise that there a difference between a process and a thread, threads are lightweight processes with less switching overhead and smaller footprint, im talking about a Java / C# style threading model and an example were this would be usefull beside the sockets server i mentined would be an efficient proxy script, current php proxy scripts are over bloated pieces of spaghety code written by script kiddies (which is generaly true of many php apps) and yes i know of mbstring extension, but once again thats all it is and extension php6 wont be out for years yet
Despite all the criticism I'm reading here, it still beats .aspx for database implementation, HANDS DOWN.