Slashdot Mirror
Recently Exposed PHP Hole's Official Fix Ineffective
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."
No licensing
stable
no licensing
great track record
no licensing
flexable
no licensing
modules for everything
no licensing
PHP: Pretty Hard to Protect.
Never shake hands with a man you meet in a fertility clinic.
Facebook, but if the question is "Who runs a site in PHP using CGI mode that is worth exploiting?" then it gets harder to answer.
Available from the source, not information week.
The info I was looking for:
- FastCGI installations are not vulnerable
- can only be exploited if the HTTP server follows a fairly obscure part of the CGI spec. Apache does this, but many other servers do not.
I generally don't feed your kind, but if PHP was from Microsoft it would be left unpatched for Windows Server 2003, Windows Server 2008 would get a temporary patch blocking most of the functionalities and there would be an announcement that, due to technical restrictions, everybody needs to upgrade to Windows Server 2013 (release date : late December 2015) to get an actual fix. People running iis on XP, Vista or Win7 wouldn't get a patch at all. Of course, anybody running another server than iis would be left in the cold too.
On the positive side, it could be worse ... Apple would just ignore any mention of security problems and systematically erase any posts on their message board refering to them.
That being said : you might want to steer away from PHP anyway. it's a stinking pile of donkey dung
Cheers
"DRM is like the Ford Pinto: it's a smooth ride, right up the point at which it explodes and ruins your day."-C.Doctorow
I think this short snippet from Rasmus is priceless:
Yeah, passing arguments with full shell expansion to the bloody binary from the unsecure web sounds like a brilliant idea! Who would want to disallow that?!
It was pretty funny so far, but then I've seen this:
The PHP security people sat on this 0day remote code exploit for four months, ignoring multiple attempts to get them to fix this serious vulnerability. That makes me feel angry, sometimes incompetence is just not funny anymore.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Millions of people.
What is worth exploiting? Anything that you can turn into a node in your massive botnet.
http://php.net/license/index.php PHP has a license which must be respected by law. Certain parts of it have various licenses too. These are Open Source licenses, and as such have many benefits. Nevertheless, there are licenses.
The answer is Facebook, and I got a job by using this bug against them! see?
There is ignorance, all right, between your ears. All languages have security flaws and need constant patches. PHP has robust and well tested frameworks with libraries to sanitise potentially dangerous input. There is nothing that can be done in say Ruby (my favorite language) that cannot also be done well in PHP. PHP now even has closures, lamda, internal iterators....
My web host pushed this patch into user htaccess for those users clueful enough to be running php as cgi: .? - [F,L]
RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|- [NC]
RewriteRule
Shared hosting at this ISP, a well-regarded one, disables normal PHP's ability to write files unless you open up directory permissions (777). Last time I checked, other users could also read files unless you used 600. Two problems, hence, they support php-cgiwrap if you know enough to want it.
Running PHP as cgi is the only reasonable choice at shared hosts like this, with a robust, but essentially legacy, Linux structure.
Seems crazy. CloudLinux does segregate users (nothing to do with a cloud, by the way), and other Linuxes can be protected various ways (FutureQuest has done shared hosting right for a long time.)
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).
Greylisting is to SMTP as NAT is to IPv4
> No licensing
Wrong
> stable
This news post is proof that's wrong.
> great track record
Wrong.
> flexable
About as flexible as your spelling.
> modules for everything .. all in the core API.
This is true. AND THEYRE ALL PART OF THE CORE API! ImageMagick, MySQL (THREE TIMES!), Curl, etc
PHP is a fucking disgrace and a blight on the world and needs to die a fiery death.
(Spend a few minutes reading the url I linked above at veekun.com for a wonderful break won on why PHP is a heinous pile of horseshit.)
As compared to say C or C++? Nonsense, proper programming techniques must be done in ANY language for stability, scalability, security.
That is your counterargument?
https://www.google.nl/search?client=opera&rls=en&q=massive+security+hole+ruby&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest#sclient=psy-ab&hl=en&safe=off&client=opera&hs=7y2&rls=en&channel=suggest&q=security+hole+rails&oq=security+hole+rails&aq=f&aqi=&aql=&gs_l=serp.3...11909.11909.2.12120.1.1.0.0.0.0.171.171.0j1.1.0...0.0.M8PkiUtwDPo&psj=1&bav=on.2,or.r_gc.r_pw.r_cp.,cf.osb&fp=81cfb75de4601914&biw=1725&bih=1037
READ the snippet google gives for the first result.
Back then, every rails fan tried to wave the massive by default security flaw as being unimportant. This PHP thing only affects those running CGI which is pretty are and BAM, it is a massive flaw and the end of the world.
Pieces of software and hardware are sometimes design with the wrong assumptions, it happens. Follow the industries best practices, or become a fanboy and burry your head in the sand when it is your pipelines turn to be ridiculed.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
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.
Yea, this PHP bashing here gets really old. Sure, the fact that it's a high level language attracts some clueless programmers that write bad code, but that's not the languages fault. I happen to be in a position right now where I do most of my coding in PHP. There are in fact things about it that drive me crazy, but the fact is that you can write great stuff with PHP and you can do it very quickly. As far as this exploit goes, who actually uses PHP in cgi mode rather than as an Apache module?
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.
Huh, the practice is even recommended by Zend. Isn't PHP great, where a closing tag is a vector for bugs?
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
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 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.
Dewey, what part of this looks like authorities should be involved?
"who actually uses PHP in cgi mode rather than as an Apache module?"
Precisely - I've never heard of anyone doing it that way. And that veekun article has certainly made me think that the billions of PHP based sites that have never had a problem will soon realise their folly! Mwahaetc.
Please consider this account deleted, I just can't be bothered with the spam anymore.
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:
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!"
Dewey, what part of this looks like authorities should be involved?
Apache is old news. It's bloated and there are security advisories for it all the time. I can't believe anyone uses that anymore. I, like many other admins, start by writing a webserver using the bourne shell:
http://sprocket.io/blog/2008/03/writing-a-web-server-in-bourne-shell/
Then, all of the web development is done using LISP. LISP is much cleaner to write a CGI program in than the bourne shell. Here's a CGI LISP tutorial that includes a comparison of the two:
http://cybertiggyr.com/lc/
No need to thank me for getting you up to speed on the latest web development techniques... but you're welcome.
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...
They do have a great track record at being consistently horrific...
Prepared statements. Even PHP supports them, although they don't emphasize that fact enough (such as by causing calls to mysql_query to segfault, or ideally make the server hosting it catch on fire).
I say that in humor, but I'm actually dead serious about always using prepared statements - in any language - over directly executing concatenated query strings. It's one thing if you're the person writing the DB interface library that everything runs through and the database itself doesn't provide some kind of facility for helping you. In that case, you go to heroic lengths to test, test, test that your library is bulletproof. But most people aren't writing client libraries; they're writing apps that use them. Those people should never be manually building query strings. Not "well, not usually but..." or "there are some situations where...". No there aren't. Don't do that or let anyone else around you do it, either.
Dewey, what part of this looks like authorities should be involved?
There's no need to escape things before passing them to MySQL, just use PDO (or mysqli) prepared statements.
Greylisting is to SMTP as NAT is to IPv4
Which is, in fact, available in PHP. Any PHP programmer not entirely retarded knows to use prepared statements. The docs Just Some Guy posted are from the bloody ancient mysql library which is hardly in use any more. They're of course still available, for backwards compatibility, so obviously the documentation has to be too.
Note that I'm not defending PHP, I find it a complete mess. But ragging on for the wrong reasons is just dumb and won't convince anyone. Now, if you were to criticise the insane inconsistency in the standard library--such as never being able to decide on camel case or underscores, the consistent inconsistency of needle/haystack parameter ordering, and so on and so forth--or the fucked up automatic type casts and equality operators, then you'd be making a point.
you are already using a programming language which is surely more capable than a stupid POSIX shell! (If not, you REALLY need to switch languages.)
Which is exactly the point: one needs to switch languages because according to the "fractal of bad design" essay all PHP has is a counterpart to system(), not a counterpart to exec*() or spawn*(): "There is, as far as I can tell, no way to safely spawn a process. You can ONLY execute a string via the shell." This goes double for Windows, where pcntl_*() is not implemented and escapeshellcmd and escapeshellarg have completely incorrect behavior. Even under Linux and FreeBSD, --enable-pcntl is turned off by default; PHP must be recompiled to turn it on.
I'd look at it exactly the opposite - people are defending it because they use it and know it's quirks, not because of the financial angle.
I mean, any languag -- even Javascript -- becomes decent once you have written years of code in it. The underlying language may be crap, but it's what you make of it that matters.
Personally, I like PHP for the above reasons - I learned it early on, because it was available on free webhosts(running a LAMP stack) and found it worked for me. /easy/ some things are - I recently did a project for my employer(Note: I /don't/ work in IT) creating some forms and displays off of a mixture of MS Access databases(via ODBC), MS SQL server databases(via ODBC), and some MySQL for caching. PHP worked surprisingly well, making it simple to handle all sorts of data and display nice, usable interfaces. Sure, there are better options on both the front and backend(MS Access for a DB? Really?), but the fact is that it /worked/ and was quick to prototype. And when you're building something to get the job done with minimal-to-none support from IT... That matters.
Now, I like it a bit more decently because of how
With Ruby, you can supposedly build a website in 15 minutes. That's all I need to know to keep away from it.
That's Rails, not Ruby.
Anyway, you've got strange criteria. Because a language is productive (without encouraging bad habits like PHP does, I must add), you don't want to know about it? Is that because you bill by the hour?
I'd love Python, if it wasn't so god damn slow. Only way to make it go fast is to write what you want to do in C.
The irony is that Python interpreter is actually faster than PHP interpreter. And then there's JPython, IronPython and PyPy, which are all faster than PHP with various "accelerators". The only thing that might be as fast from PHP side is HipHop, and even then I doubt they actually optimize as good as PyPy JIT (but it would be interesting to benchmark).
PHP is the Windows of the scripting world.
They both evolved out of a low-brow, poorly deigned mess, they both blame everything on 3rd party developers, and they are both insanely popular despite their shortcomings.
So, Microsoft used aggressive marketing to become so popular. What's PHP's draw?
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*.
There is no sig...
There's a LITTLE problem with your pronouncement (besides the unbecoming heat). It ain't so. China, Korea, Iran, Japan, Hungary, Lithuania, and Belize also put the month first. In addition Canada, Nepal, South Africa, Austria, Portugal, Sweden, Norway, Denmark, Philippines, and Saudi Arabia have mixed usage regards DD-MM/MM-DD. Where's your consensus now?
Actually there IS a true international consensus in the form of ISO 8601 International standard, which is YYYY-MM-DD. As of ISO 8601:2004, no component may be left out or truncated on either end. Unlike your favored format, this has the following advantages:
1) It is COMPLETELY unambiguous and requires no cultural agreement to interpret.
2) It sorts left-to-right just like any number or alpha string.
2a) Therefore when used as a part of a filename, files are properly sorted in a an alphabetical directory listing.
Face it, both US (MM-DD-YYYY) and other provincial conventions are stupid. Even if the US convention is a little more stupid than the (most of) European because it sorts NEITHER left-right nor right-left, they are BOTH stupid, There is absolutely NO reason whatsoever not to use ISO 8601 for ALL date specifications.
New users are advised to use MySQL Improved mysqli_ functions
That's a user comment, not part of the official documentation, and it was added today. At least it's a little documented now as of 11 hours ago.
The fact that every function under the mysql extension has the note..
No it doesn't. I'm looking at it right now, at http://www.php.net/manual/en/function.mysql-query.php, and that string does not exist on the page.
The fact that most new users will be using a framework rather then directly writing everything anyway.
Oh, so the language admittedly sucks, but frameworks abstract that suckiness away from new users. Way to move the goalposts.
Just face it, you don't know what you're talking about, stop acting like a little kid.
You're not very good at the whole "staying on subject and presenting evidence" things, but that's OK. It'll come to you with time if you keep at it.
Dewey, what part of this looks like authorities should be involved?