Recently Exposed PHP Hole's Official Fix Ineffective 240
wiredmikey writes "On Wednesday, a remote code execution vulnerability in PHP was accidentally exposed to the Web, prompting fears that it may be used to target vulnerable websites on a massive scale. The bug itself was traced back to 2004, and came to light during a recent CTF competition. 'When PHP is used in a CGI-based setup (such as Apache's mod_cgid), the php-cgi receives a processed query string parameter as command line arguments which allows command-line switches, such as -s, -d or -c to be passed to the php-cgi binary, which can be exploited to disclose source code and obtain arbitrary code execution,' a CERT advisory explains. PHP developers pushed a fix for the flaw, resulting in the release of PHP 5.3.12 and 5.4.2, but as it turns out it didn't actually remove the vulnerability."
You shouldn't. Nobody should. (Score:1, Insightful)
The only reason to use PHP is ignorance. There have always been far better options available, and anyone who wasn't a fucking idiot used them.
There's no valid reason to use PHP today. None at all. Python, Ruby, and even Perl are far better languages, and they all have extensive and robust libraries and frameworks for developing web apps. Java and C# are two other options, and in some ways are much better than Python, Ruby and Perl, especially for larger apps worked on by many developers. Then there are numerous other frameworks for less-common languages like Haskell, Erlang, Smalltalk, and Scala, as well.
PHP's numerous and fundamental security problems shouldn't be an issue for anybody, since nobody should be using PHP in any way.
Re:Cm'on (Score:4, Insightful)
Millions of people.
What is worth exploiting? Anything that you can turn into a node in your massive botnet.
Re:You shouldn't. Nobody should. (Score:4, Insightful)
Well, PHP has many flaws and all but I've had to maintain plain ASP/VB websites and PHP5 is miles better than that. PHP3 or ASP/VB? Well, that's a little tougher but PHP5 is just so much better than VB. As for ASP.NET (using VB or C#), that's a whole other thing. PHP doesn't compare very well to C#.NET or even VB.NET (yes, I know both are .NET and have pretty much the same features, C# is just a more pleasant language to work with).
Re:And (Score:5, Insightful)
Out of interest, what does the "great track record" refer to? The security has historically been consistently horrific, the performance has historically been consistently horrific, the consistency of the language has been consistently horrific, the development of the language has been consistently horrific...
I do miss the documentation, now that was awesome. But I don't miss the rest of it.
Re:Training wheels without the bike (Score:3, Insightful)
I agree this is a pretty pathetic show of professionalism from the PHP team's part.
The bug is serious, i don't know why there was even any discussion of whether or not it is a bug. It's a textbook case of not properly handling user input.
The only thing that dampens the impact of this, is that it only impacts the CGI version of PHP. Most installations that i'm aware off, use PHP in either a SAPI or FastCGI setting, which as far as i'm aware do not use the codepath that contains this bug.
I use PHP pretty heavily in my job, but i'm getting more and more tired of the way the project is ran. The project has some pretty clear issues that all seem to take ages getting resolved. I've often contemplated wether or not it would be worth making a fork of the project (for internal use in the company where i work) just so we could fix some of the major issues that have fouled PHP for ages now. I'm aware of several OSS projects that are attempting the same, but unfortunately none of them appear stable enough to be used for business critical applications, which makes me fear that i underestimate the amount of work that needs to be done to polish this turd.
Now that magic quotes and register globals have finally been killed off after years of working around that mess, i started hoping that someone on the PHP team grew some balls and was beginning to push through some of the glaringly obvious fixes to PHP.
With reasonable namespace support, there's no reason why all of PHP's functions should still be in the global namespace, and segregating them in the appropriate namespaces would finally give them a chance to fix the annoying differences in function naming and argument order, that PHP still has (for legacy reasons). This would clean up PHP tremendously for new users and would only pose a small adjustment on current users. A single configuration directive (disabled by default) could simply recreate the old functions in the global namespace, make them throw a E_STRICT notice (or something similar), and call the appropriate function from its new location.
Many of the older/core PHP functions still use errors or empty return values, whereas all the new stuff uses Exceptions. Many experienced developers tie those together by using things like ErrorExceptions but this should just be overhauled into 1 single style (Exceptions being the most powerful one, those should probably be standardized on).
Ever since version 5, PHP has made good progress moving towards an object oriented style of programming. However since the scalar types (String, integer, boolean, etc) are not considered to be objects, and very different rules are placed on objects compared to non-objects, another conflicting style of programming is presented. Scalar values should be able to be treated as objects (even if they're not on a fundemental level) to unify things like type hinting and passing by value/reference.
It is my feeling that these changes would greatly improve the usability of PHP for both new and seasoned developers. It would simplify the language, and make it more powerful at the same time.
Re:You shouldn't. Nobody should. (Score:5, Insightful)
Re:You shouldn't. Nobody should. (Score:4, Insightful)
requires you to learn a hundred different quirks and hacks
I really don't know what quirks and hacks you're talking about. Any language has to be learned, and as long as you escape your strings before passing them to MySQL, sendmail, or another application, PHP is secure. The hole they're talking about here is an escaping problem. Although it sounds like this is actually a flaw in PHP, the method that makes it possible shouldn't be used today anyway. And you're not going to avoid escaping problems in any language that does what you're doing in PHP.
Re:You shouldn't. Nobody should. (Score:3, Insightful)
There is nothing that can be done in say Ruby (my favorite language) that cannot also be done well in PHP.
In a theoretical computer science sense, you're correct. In practice, you couldn't be more wrong. In nearly 20 years of development, PHP has never managed to do things the right way on any objective scale. For example, last year PHP had a major crypto bug [slashdot.org] in a released version which failed unit tests. Let me repeat that: PHP's own unit tests failed but they still shipped it, distributing a major security flaw to all users.
PHP is unfit for major software development, and PHP's authors and maintainers are unfit to write and maintain it. Yeah, I said it. Yes, it's "just as good" as Ruby, Python, or other competing problem-space solutions in a strict Turing-completeness way, but in all pragmatic senses it has been a complete and utter rolling disaster.
Yes, it's popular. So are McDonald's hamburgers. That doesn't mean I'd want to deal with either on a regular basis.
Re:You shouldn't. Nobody should. (Score:5, Insightful)
as long as you escape your strings before passing them to MySQL
You know, I only hear PHP developers saying stupid shit like that. No one in Python talks about escaping strings (unless they're writing database libraries). Rubyists don't escape strings. Perl monks sure as hell don't escape strings. VB(\.Net)? programmers might escape strings, but we don't really count them. No one escapes strings anymore because it's stupid, error prone, and dangerous.
And yet PHP coderz still do it. Why? Oh, right: because the official docs teach them to [php.net]:
Fucking hell. In 2012, we're still exposing newbies to that idiocy, and when they do it poorly and some kid in Latvia owns a major PHP project as a result, defenders jump out to yell "it's the programmer, not the language!"
Re:You shouldn't. Nobody should. (Score:2, Insightful)
Re:You shouldn't. Nobody should. (Score:4, Insightful)
And MD5 salts were (and if I'm not mistaken, still are) the default. So by default, you'd be insecure.
The bigger point is that *even though the PHP core's own unit tests failed, they still shipped a release* - this is an indication that the PHP core team has no clue. You do not ship a release when your core unit tests *are failing*.