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

Comments

Re:And

[jhoegl]

No licensing
stable
no licensing
great track record
no licensing
flexable
no licensing
modules for everything
no licensing

I finally know what PHP stands for.

[DieByWire]

PHP: Pretty Hard to Protect.

Re:I finally know what PHP stands for.

[gstrickler]

I thought it meant Pointy Haired Programmers.

Re:I finally know what PHP stands for.

[jo42]

Piled High Poop more like it.

PHP Objected Oriented Programming: POOP.

Re:I finally know what PHP stands for.

[MurukeshM]

You must be a PHP developer, probably of the team that "patched" this hole.

Re:I finally know what PHP stands for.

[grcumb]

PHP: Pretty Hard to Protect.

Back in the late '90s it was Poorly Hung Perl.

The beauty of the statement is, the less you like Perl, the greater the insult to PHP. 8^)

Re:Cm'on

[SolarCanine]

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.

Actual Details...

[Anonymous Coward]

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.

You shouldn't. Nobody should.

[Anonymous Coward]

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:You shouldn't. Nobody should.

[rubycodez]

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

Re:You shouldn't. Nobody should.

[mikael_j]

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:You shouldn't. Nobody should.

[LVSlushdat]

Yeah.. I'm gonna listen to a flippin' AC on whether I should use PHP or not... I laugh...

Re:You shouldn't. Nobody should.

[Anonymous Coward]

Ruby is your favorite language? Oh you poor soul.

Re:You shouldn't. Nobody should.

[rubycodez]

As compared to say C or C++? Nonsense, proper programming techniques must be done in ANY language for stability, scalability, security.

Re:You shouldn't. Nobody should.

[rubycodez]

That is your counterargument?

Re:You shouldn't. Nobody should.

[rubycodez]

No, I'm quite well paid, thank you very much.

Re:You shouldn't. Nobody should.

[TheRaven64]

Yes indeed, C and C++ are the languages I always think of when it comes to web development. Most especially used with the StrawMan++ framework.

Re:You shouldn't. Nobody should.

[TheRaven64]

Ruby's not that bad, if you can manage to avoid having any interaction with the Ruby community...

Re:You shouldn't. Nobody should.

[digitalaudiorock]

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?

Re:You shouldn't. Nobody should.

[rubycodez]

oh, your company's httpd and its modules are written in a script, and not C? do tell. your web framework language of choice isn't written in C or C++, do tell. Of course YOU DO use C or C++ for web facing wares.

Re:You shouldn't. Nobody should.

[mcavic]

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.

[mcavic]

Yes, it does make security hard. But I don't think it's the language. I think it's the fact that you're interfacing a web server, a backend script, and MySQL database. Most of the insecurity has to do with the interfacing, not the script itself.

Re:You shouldn't. Nobody should.

[Just Some Guy]

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.

Re:You shouldn't. Nobody should.

[History's Coming To]

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

Re:You shouldn't. Nobody should.

[Just Some Guy]

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:

// Formulate Query
// This is the best way to perform an SQL query
// For more examples, see mysql_real_escape_string()
$query = sprintf("SELECT firstname, lastname, address, age FROM friends
WHERE firstname='%s' AND lastname='%s'",
mysql_real_escape_string($firstname),
mysql_real_escape_string($lastname));

// Perform Query
$result = mysql_query($query);

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.

[rubycodez]

in practice, you couldn't be more silly, you link to article about people who call crypt() with only an md5 salt? what idiot does that? not any wares I've ever written nor seen.

Re:You shouldn't. Nobody should.

[mcavic]

Of course it's error-prone, but how else can you avoid SQL injection in any language?

Re:You shouldn't. Nobody should.

[Just Some Guy]

in practice, you couldn't be more silly, you link to article about people who call crypt() with only an md5 salt? what idiot does that?

Your reading comprehension fails. People expect:

crypt('string', 'salt') === 'saQ9i9dEI8LLA';

to return TRUE. Instead, they got:

crypt('string', 'salt') === 'salt';

So if you used the crypt function to hash and store site passwords, you weren't really storing the hash: you were just storing the salt itself. And when it came time to verify that "hash but really just the salt" by comparing it with the user-submitted password that had been crypted with the same salt, the comparison always came back true. Joyous day!

not any wares I've ever written nor seen.

Ah, I think I've found the disconnect. Would you like a lollipop?

Re:You shouldn't. Nobody should.

[rgbrenner]

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.

Re:You shouldn't. Nobody should.

[Just Some Guy]

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.

Re:You shouldn't. Nobody should.

[mcavic]

So do it yourself. Sanitize your variables, prepare your statement, and then pass it. If you're going to use a language, you should be able to use it correctly. And it's really not that much of a chore once you're used to it. Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.

Re:You shouldn't. Nobody should.

[mikael_j]

There's no need to escape things before passing them to MySQL, just use PDO (or mysqli) prepared statements.

Re:You shouldn't. Nobody should.

[Just Some Guy]

So do it yourself. Sanitize your variables, prepare your statement, and then pass it.

You're wrong. Not difference-of-opinion wrong, but factually-incorrect wrong. What benefit do you get from re-inventing a language feature that's already there and (well, hypothetically in the case of PHP) well tested? Do you also write your own for loops with goto because it's more flexible?

And it's really not that much of a chore once you're used to it.

I swear to God, I hope you're trolling. Why make it a chore at all instead of letting the language libraries handle it? In your own words: if you're going to use a language, you should be able use it correctly. All modern languages provide facilities for doing things the right way, so what possible motive would you have for deliberately and painstakingly doing things the wrong way?

Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.

So keep sanitizing shell commands until PHP catches up to other languages there, but do things the easy and right way in your database logic. You're allowed to use both a hammer and a pliers for different tasks, you know.

Re:You shouldn't. Nobody should.

[Stormtrooper42]

Exactly.
And it does exists in PHP.
You can do that with PDO for example, which is also database agnostic.

Re:You shouldn't. Nobody should.

[Overly Critical Guy]

Are people seriously defending the use of PHP in 2012? You talk about testing when PHP doesn't even pass all its own tests according to the official website.

PHP's creator has publicly stated that he is not a programmer and is not interested in being one, that he didn't set out to create a programming language, and so forth.

When I see people defending PHP, I have the same reaction I get when I see Scientologists defending a religion started by a science fiction author.

Re:You shouldn't. Nobody should.

[Overly Critical Guy]

You know, every time I see someone on a forum defend PHP, they eventually admit that they write PHP for their job. If you have a vested financial interest in PHP, it's understandable that you'd have a desire to defend your source of income, but it doesn't change the fact that PHP is objectively a terrible language. Just because the PHP bashing is old doesn't make it wrong.

Re:You shouldn't. Nobody should.

[Stormtrooper42]

When I started reading your comment, I thought you were going to write something serious, about nginx or lighttpd... You got me.

Re:You shouldn't. Nobody should.

[SendBot]

A good language makes it easy to do things right and hard to do them wrong.

Then for your paranoid sake, stay the hell away from Javascript! Actually... you'd better stay away from computers all together. Just back away slowly, and get a friend to unplug it for you. If you don't have any friends, just set the house on fire and you'll make some new ones pretty quick.

Re:You shouldn't. Nobody should.

[tepples]

And you're not going to avoid escaping problems in any language that does what you're doing in PHP.

Say you have an SQL statement that takes a varying number of parameters. This could be a statement generated by a query-by-example engine or a statement using operator IN . The MySQLi module makes it very hard to use a prepared statement with ? placeholders for all user-supplied pieces of data: the program has to keep three different lists in sync and use call_user_func_array(), whose semantics vary from PHP version to PHP version. Python's database API, which always uses an array of arguments, makes this somewhat less of a chore.

Re:You shouldn't. Nobody should.

[tepples]

As far as this exploit goes, who actually uses PHP in cgi mode rather than as an Apache module?

Customers of shared web hosting plans, for one.

Re:You shouldn't. Nobody should.

[Anonymous Coward]

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.

Re:You shouldn't. Nobody should.

[theArtificial]

This made me laugh so hard. Thanks!

Re:You shouldn't. Nobody should.

[amorsen]

Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.

No you don't. You have no reason to call the shell -- 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.) Call the program directly without invoking the shell.

This is a bit of a misfeature in Unix / C; system() is easy while the right way requires you to do fork() and exec() by hand. There is no reason to repeat that mistake in modern languages.

Re:You shouldn't. Nobody should.

[anss123]

The MySQLi module makes it very hard to use a prepared statement with ? placeholders for all user-supplied pieces of data: the program has to keep three different lists in sync and use call_user_func_array(),

Sounds overcomplicated.

Just create a function that creates a string of n ", ?" that you put into the prepared statment, then do as usual.

I.e: prepare('select column from table where column in ('+create_qmarks(array_of_values.length)+')');

If you want to supply the values in an array, create a function that loops through an array and calls "bind param", or whatever MySQLi prepared statments use, for each value in the array.

Hardy difficult, and no need for "call_user_func_array" while maintaining three lists? Don't think I quite understood you there...

Re:You shouldn't. Nobody should.

[Stormtrooper42]

Why does his reading comprehension fail?
This bug was indeed limited to md5 salts.

Re:You shouldn't. Nobody should.

[Stormtrooper42]

If you consider PHP as "unfit for major software development", I'm pretty sure there are many other languages you wouldn't use.
What is your language of choice, when it comes to web development ?

Re:You shouldn't. Nobody should.

[reve_etrange]

Structured programming theorem. Just so no one reading this gets the idea that goto is in fact more flexible, though it might seem that way at first glance.

Re:You shouldn't. Nobody should.

[RobbieThe1st]

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.
Now, I like it a bit more decently because of how /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.

Re:You shouldn't. Nobody should.

[RobbieThe1st]

Wait... what? I always thought it was done via Apache. Doesn't using mod-cgi require all your files to be in a folder like cgi-bin? All the free hosts I've used /seemed/ to use the Apache mod and PHP files would run anywhere inside your www directory.

Unless I'm misunderstanding you.

Re:You shouldn't. Nobody should.

[Anonymous Coward]

No, you need to control HTML passing back and forth with htmlentities and html_entity_decode. Make sure to lock in the charset too to avoid MITM attacks.

Re:You shouldn't. Nobody should.

[digitalaudiorock]

It is the lang fault if easier to do wrong than right

Wow...no wonder you posted anonymously. This may be the single silliest thing I've ever read here or anywhere. So other high level languages make it difficult to "do wrong" if you don't have a clue what the fuck you're doing???

Re:You shouldn't. Nobody should.

[digitalaudiorock]

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.

Thanks you...exactly my point. You can write great code in just about any mature language if you understand it properly. There are many situations where PHP might be a bad choice depending on your needs, but to just write off a whole language and everything written in it simply because it's written in PHP or any other language is absurd and just plain silly.

Re:You shouldn't. Nobody should.

[shutdown -p now]

http://www.webtoolkit.eu/wt

Re:You shouldn't. Nobody should.

[shutdown -p now]

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

Re:You shouldn't. Nobody should.

[Bill, Shooter of Bul]

Yeah, it also has this:
http://us.php.net/manual/en/pdo.prepare.php

You can still kill yourself in C++ many ways as well, you just have to be smart enough to not shoot yourself in the foot.

Re:You shouldn't. Nobody should.

[TheRealMindChild]

PHP5 was released in 2004. I was using VB/ASP (I'm assuming VB6/ASP classic?) in 1998. There is perspective you are deliberately leaving out.

Re:You shouldn't. Nobody should.

[TheRealMindChild]

All languages have security flaws and need constant patches.

QBasic doesn't

Re:You shouldn't. Nobody should.

[TheRealMindChild]

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.

VB6 wants its argument back

Re:You shouldn't. Nobody should.

[Kalriath]

If you're using .NET (any .NET language) MSDN Document Writers will fall from the sky to assassinate you if you write an SQL query without using SqlCommand and Parameters.

Re:You shouldn't. Nobody should.

[Kalriath]

FastCGI is unaffected. I've tested (not like testing this issue is hard).

Re:You shouldn't. Nobody should.

[Just Some Guy]

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.

But Google for "php mysql" and you'll get a list of the old-style functions, including "mysql_query", as the first search result. If PHP wanted to clear up the confusion, they should prominently mark those docs as being old-style and that new development should use PDO - but alas, they don't. You and I know that you shouldn't be using mysql_* for most things, but how would a new user who wants to use PHP and MySQL together know that?

Re:You shouldn't. Nobody should.

[discord5]

Of course it's error-prone, but how else can you avoid SQL injection in any language?

Most languages support prepared statements that properly handle strings for you. Take a look at the python API for databases (this is sqlite3, but other dbs use the same system).

Straight from that page:

t = (symbol,)
c.execute('SELECT * FROM stocks WHERE symbol=?', t)

Notice the lack of escape_my_strings_no_really_please_this_is_the_right_method("string");. Clean huh? People still using sprintf() or string concatenation for this sort of thing after all these years reap what they sow.

As for your post below:

Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.

The fact that you're even contemplating on running shell commands based on user input is pretty much damning in my opinion.

I guess you're the type of person they sell those SQL-injection-protection proxies to.

Re:You shouldn't. Nobody should.

[Jaxoreth]

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.

Godwin's Law applies just as well to programming language advocacy: If your defense of a language requires pointing out that it's Turing-complete, you lose the argument.

Re:You shouldn't. Nobody should.

[LingNoi]

I can think of plenty of reasons,

- client wants it
- only x months to build something and most of the team only knows it
- pre-existing code base

I'm sure you have many childish retorts for all these points however..

Re:You shouldn't. Nobody should.

[LingNoi]

Yeah, PHP has that too.

Re:You shouldn't. Nobody should.

[LingNoi]

So then this is about your ignorance rather then anything else. That's usually where hate comes from which makes sense why you hate something you hardly know anything about.

Re:You shouldn't. Nobody should.

[Just Some Guy]

I think I probably know a lot more about it than you do, dear child. But you didn't answer my question: how would a new user - not you, not me, but someone trying PHP for the first time - know not to use mysql_*?

Re:You shouldn't. Nobody should.

[MadCat]

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

Re:You shouldn't. Nobody should.

[LingNoi]

http://php.net/manual/en/book.mysql.php

New users are advised to use MySQL Improved mysqli_ functions rather than the older [replaced] mysql_ functions where applicable and subject the appropriate latest stable versions of Apache, php and MySQL, etc.

The fact that every function under the mysql extension has the note..

Use of this extension is discouraged. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API for more information.

The fact that most new users will be using a framework rather then directly writing everything anyway. Just face it, you don't know what you're talking about, stop acting like a little kid.

Re:You shouldn't. Nobody should.

[Just Some Guy]

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.

Re:You shouldn't. Nobody should.

[benjymouse]

t = (symbol,)
c.execute('SELECT * FROM stocks WHERE symbol=?', t)

Or

var t = "string";
db.Stocks.Where( s => s.symbol == t );

Simple, concise, strongly typed, safe, LINQ

Re:You shouldn't. Nobody should.

[benjymouse]

If you're using .NET (any .NET language) MSDN Document Writers will fall from the sky to assassinate you if you write an SQL query without using SqlCommand and Parameters.

I wouldn't dream of using SqlCommand any more. I've always hated how verbose those are, how you have to "add" the parameters. They actually make writing secure code harder (exatctly like PHP) and will lead some developers to just fall back to string concatenation (PHP is a little worse in this regard as it makes synthesizing the string *much* easier with string interpolation).

In .NET one should use LINQ. Use Entity Framework - even if you will not build up an entire model. Or use NHibernate. Just use something where you can query using LINQ.

Re:You shouldn't. Nobody should.

[rgbrenner]

I've heard of nginx before.. but it's written in C, and C should not be used on the internet. When they do a complete rewrite in a non-C langauge, like the bourne shell, then maybe I'll take them seriously.

Re:You shouldn't. Nobody should.

[micheas]

No but it is a cool first real program for an intro to programming class.

Most students can do it in someplace between 500 and 1500 lines. The only problem is to introduce it late enough and with enough help so that they don't just try and copy it.

The help isn't because they really need it, it is so that they have the self confidence to actually try it.

Re:You shouldn't. Nobody should.

[micheas]

The reason why people use php is because of wordpress, drupal, joomla, symfony, yii, cake, and the rest of the eco system around the language.

I wonder how much of the reason php, asp, and java are just because of marketing that allowed them to figure out how to get new developers interested in the technology.

Re:You shouldn't. Nobody should.

[micheas]

Python fits that description for the most part. It doesn't mean that there are not clever idiots writing crap in python, but the idiots have to work at it.

Re:You shouldn't. Nobody should.

[mikael_j]

That's for entirely different reasons, to protect yourself from SQL injection attacks prepared statements should be all you need (if used properly).

Re:You shouldn't. Nobody should.

[Kalriath]

Oh dear god no, do NOT use Entity Framework. That monstrosity generates SQL that no server ever created could optimise, and deliberately avoids using indexes and catalogs. Generally, selecting 5 columns from a table requires three joins, a table scan, and two unnecessary sorts. If you're going to query a DB and want to use an L2S provider, either use Linq2SQL directly, NHibernate, or LightSpeed.

Re:You shouldn't. Nobody should.

[rubycodez]

only morons do it that way, good practice is to concatenate and use single argument form, after verifying each component not null.

Re:You shouldn't. Nobody should.

[rubycodez]

wrong, writing application-helping modules can be a hard core form of it. a far cry from the usual artsy-fartsy crowd's endeavors

Re:Microsoft Sux!

[sammyF70]

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

Training wheels without the bike

[A beautiful mind]

I think this short snippet from Rasmus is priceless:

The point of the question here is if anybody remembers why we decided not
to parse command line args for the cgi version? I could easily see it
being useful to be able to write a cgi script like:

    #!/usr/local/bin/php-cgi -d include_path=/path

and have it work both from the command line and from a web context.

As far as I can tell this wouldn't conflict with anything, but somebody at
some point must have had a reason for disallowing this.

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:

13-01: Vulnerability discovered, used to pwn Nullcon Hackim 2012 scoreboard
13-01: We discuss the issue with Nullcon admins, find out it is a php 0day
17-01: We contact security@php.net with a full report and a suggested patch
01-02: We ask PHP to confirm receipt, state our intent to hand off the vulnerability to CERT if progress is not made
01-02: PHP forwards vulnerability report to PHP CGI maintainer
23-02: CERT acknowledges receipt of vulnerability and attempts to contact PHP.
05-04: We ask CERT for a status update
05-04: CERT responds saying that PHP is still working on a fix
20-04: We ask CERT to proceed with disclosure unless a patch is imminent
26-04: CERT prepares draft advisory.
02-05: CERT notifies us that PHP is testing a patch and would like more time. we agree.
03-05: Someone posts a mirror of the internal PHP bug to reddit /r/netsec /r/opensource and /r/technology. It was apparently accidentaly marked public.

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.

Re:Training wheels without the bike

[Anonymous Coward]

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:Training wheels without the bike

[youn]

Any, love you man! I may not agree with all your opinions, but they are often very interesting. We are all waiting impatiently for your forked rewritten version of PHP :p

Re:Training wheels without the bike

[youn]

oh anyone can complain... but given I use php on a daily basis, I definitely would welcome any improvements :)

i don't necessarily agree with all the changes that guy wants though... and having had to port code from version to version, I can certify that the breaking compatibility on a regular basis is really annoying, not necessarily making things more secure... or there could have been alternatives providing less pain

Re:Cm'on

[hendridm]

Millions of people.

What is worth exploiting? Anything that you can turn into a node in your massive botnet.

Re:Problem solved

[asdf7890]

It is a while since I last used PHP in a shared environment, but last I heard mod_php could not impersonate the owner of the running script for security purpoeses, where running php in cgi or fastcgi modes does allow this option. This has security implications when not all the users on a server completely 1005 trust each other, and even if they do it prevents accidental escalation of bugs/problems in one user's code such that it affects other user's data.

Unless this deficiency in mod_php has been addressed, there are perfectly valid reasons to be running PHP in CGI (or preferably FastCGI) mode.

false - PHP has various licensing

[rubycodez]

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.

Re:Cm'on

[nickdc]

The answer is Facebook, and I got a job by using this bug against them! see?

htaccess fix and shared hosting is why

[colfer]

My web host pushed this patch into user htaccess for those users clueful enough to be running php as cgi:
    RewriteEngine on
    RewriteCond %{QUERY_STRING} ^[^=]*$
    RewriteCond %{QUERY_STRING} %2d|- [NC]
    RewriteRule .? - [F,L]

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

Re:htaccess fix and shared hosting is why

[Skal Tura]

also it seems that lighttpd+php-fastcgi is not vulnerable.

Re:htaccess fix and shared hosting is why

[colfer]

Wordpress. Or any upload system that stores images as files not database blobs! Maybe blobs are a better way, don't know, just talking practically, basic web hosting stuff.

Re:htaccess fix and shared hosting is why

[anss123]

Why on Earth would you want a web-facing page to be able to manipulate files?

I use it for caching for a template engine and small thumbnails. Essentially I don't want "junk data" in the db.

Re:htaccess fix and shared hosting is why

[dkf]

Why on Earth would you want a web-facing page to be able to manipulate files?

So that web page developers can push hot fixes to production deployments without all that irritating business of security auditing or involving a competent system administrator. Not that this would make the site exploitable, oh no no no... There are not nearly enough facepalm meme images in the known universe to cover the retardedness of some people, and yes, there's still a great many people who "want" this.

(There are a few scenarios where it genuinely make sense, but only when thoroughly guarded and with exceptionally careful privilege dropping. Not something for a general web site.)

Re:htaccess fix and shared hosting is why

[Kalriath]

So that your assets aren't stored as DB blobs, the slowest and worst possible way in which to store files?

Re:htaccess fix and shared hosting is why

[julesh]

So that your assets aren't stored as DB blobs, the slowest and worst possible way in which to store files?

The notion that blobs are slower than files is a myth. Benchmarks show that database access is actually faster in most situations than file access (at least with MSSQL and Windows Server using NTFS).

Re:htaccess fix and shared hosting is why

[julesh]

To me, this just sounds like a reason to avoid using these systems. I don't trust their developers not to have screwed up the file manipulation, something that I know from experience to be extremely hard to get right in this context. Time after time you see web applications and frameworks whose security is undermined by a basic assumption about file handling that isn't true.

Re:htaccess fix and shared hosting is why

[julesh]

1. This is what /tmp is for. /tmp has 777 file permissions, so the requirement for setuid script execution doesn't apply to accessing it, therefore it doesn't have the problem the GP post was complaining about.

2. I wouldn't usually call thumbnails "junk data". They're actual data associated with your records, so they should be treated as such (IMO).

3. You'd get much better performance from using something like memcached rather than filesystem-based cacheing, anyway.

Re:htaccess fix and shared hosting is why

[julesh]

So that web page developers can push hot fixes to production deployments...

Reminds me of this story... A client called me a couple of months ago, asking me to look at a site he'd had built by someone else. He was getting warnings from Chrome about malware on the site. Turns out there was a PHP script left in the root folder that allowed anyone with the right password to execute any shell script they wanted... somebody in croatia had been using it to inject javascript malware droppers into his site. The irony was, it was an entirely static site: PHP should have been disabled to prevent this kind of thing happening.

Re:htaccess fix and shared hosting is why

[colfer]

No 777 should be exposed to the web. Seems to be confusion here over how small site web hosting works. The tmp is not used to host images. Also, note both the admin and public side of a CMS (how Wordpress is often used) are typically coded in PHP and the admin side must be able to manipulate content, including image files. There may be a better way, but this is how it's done.

Re:htaccess fix and shared hosting is why

[colfer]

Any decent upload script like Wordpress limits the types of files uploaded (not as much as it should in my opinion). Then apache (or other web server) restricts what type of files are publicly accessible. In case that isn't clear.

Re:htaccess fix and shared hosting is why

[anss123]

1. This is what /tmp is for. /tmp has 777 file permissions, so the requirement for setuid script execution doesn't apply to accessing it, therefore it doesn't have the problem the GP post was complaining about.

Ah, he meant "why does a webserves need to fiddle with permission bits on files?" Okay. Duno.

2. I wouldn't usually call thumbnails "junk data". They're actual data associated with your records, so they should be treated as such (IMO).

I consider it junk data as it has no real value beyond speeding up pageloads. They'll be regenerated if lost.

3. You'd get much better performance from using something like memcached rather than filesystem-based cacheing, anyway.

Perhaps, but it's not a given. The OS already does caching for you, and may do a better job deciding what needs to stay in memory than what I could throw together.

A memcache does not suddenly solve all security concerns either. The common setup is to have the memcache on a "trusted network", where anyone on the trusted network have full unrestricted access to the memcache... which is not too different from having a public temp folder on your server that anyone logged in can access.

Re:htaccess fix and shared hosting is why

[Kalriath]

Interesting, not seen one of these benchmarks so I'll have to have a look.

Unfortunately, just try that on shared hosting, where you're limited to x queries per hour.

Re:htaccess fix and shared hosting is why

[Gavagai80]

Self-updating, for one. A script can't patch itself if it can't write files, and users can't be expected to chmod.

Re:htaccess fix and shared hosting is why

[julesh]

I've been running web sites on shared hosting at a wide variety of hosts since circa 1997, and never once have I had a per-hour limit on my number of database queries. If you have, you need to change your host.

Re:htaccess fix and shared hosting is why

[Kalriath]

Agreed, but they exist.

Re:And

[drunkennewfiemidget]

> 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
This is true. AND THEYRE ALL PART OF THE CORE API! ImageMagick, MySQL (THREE TIMES!), Curl, etc .. all in the core API.

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

Just a little reminder

[SmallFurryCreature]

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.

Re:Just a little reminder

[Anonymous Coward]

That's not even comparable.

While the Rails bug was pretty bad, it was a design flaw that the developers were not convinced was a design flaw. (It was.)
It was a flaw because it made it easier for the developer to to write insecure. It would be kind of if PHP had a mysql_escape function that should never be used because it didn't really work, or a htmlspecialchars that didn't escape single quotes by default, or... Oh, wait...

This, on the other hand, is a trivial remote code execution flaw, and it works even on perfectly correct code. This is not the page developer's fault, not even a tiny bit. The only thing they could have done to protect themselves is to not use PHP.
And not only did they hold onto this bug forever, when they finally patched it, the patch was wrong.

To be blunt, PHP is a terrible language, and its core developers are mostly incompetent monkeys that are not fit to write security critical C code.
If you are starting a new project, never use it. Just about any other scripting language (Perl, Python, Ruby...) will be better, and have an actually competent programming community to boot.
If you are stuck with an existing project, you should always be running Stefan Esser's Suhosin patch, which hardens it against common programming errors, both on the C and PHP side.

Re:Cm'on

[19thNervousBreakdown]

Did they not put a closing tag there just to drive us insane?> Argh!

Re:And

[Richard_at_work]

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:And

[mcavic]

It's very fast and flexible for both Web backends and standalone applications.

the php-cgi receives a processed query string parameter as command line arguments

That's a bad setup anyway, and shouldn't be needed this century.

Re:Cm'on

[atisss]

Actually it's sane to not put a closing tag, as you might accidentally add newline or space after that, which could in some cases result in invalid response (for example xmlrpc). Especially hard to debug if it's inside some included class and breaks xmlrpc server.

However the real question is - who runs PHP using CGI mode? It's 21 century.

Re:Cm'on

[19thNervousBreakdown]

Huh, the practice is even recommended by Zend. Isn't PHP great, where a closing tag is a vector for bugs?

Re:Cm'on

[mcavic]

Interesting. That has to be intentional, though. It shouldn't happen by accident.

Re:Microsoft Sux!

[Yobgod Ababua]

You had me up until the last two sentences, which appear to be merely unsubstantiated and provocative.
I highly appreciate (and agree as Insightful) your analysis of what the response to some other software vendors would be to this sort of incident.

What would *you* write your inventory database front-end in? PHP makes it work without unacceptable overhead.
I preferentially use Perl for straight scripting work, but mod-perl just hasn't proven itself to hold up against PHP on the performance front for web-based apps, and the hooks aren't as convenient. The ability to say something like

[a href="https://blah.com/blah/blah/[?php echo $page; ?]"]LINK[/a]

is actually amazingly concise and powerful. (angle brackets turned to sqare after fighting /.s editor too long and not remembering the required dance this early in the morning)

And, for the record, I tried to use this to co-opt my PHP-based sites and... nothing happened.

Re:Microsoft Sux!

[drunkennewfiemidget]

mod_perl? 2001 called. It wants its web dev back.

Look into fastcgi and catalyst.

Re:Cm'on

[atisss]

That would be just language specifics if used outside it's purpose.

For generating HTML there is no problems with having leading/trailing spaces, however if your output needs to be strictly formatted, you wouldn't output some unrelated \n just for fun.

Re:And

[Anonymous Coward]

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

Way to miss the point.

[Anonymous Coward]

Reread the parent post again. And again.

Re:And

[DeathToBill]

God, why do you never have modpoints when you want them? This deserves so much better than '-1, Troll'.

Re:Cm'on

[DavidTC]

For generating HTML there is no problems with having leading/trailing spaces,

Uh, yes, there is. You cannot send headers after sending any output.

Which means include files (Which are obviously often run before code that sends headers.) cannot have such extra space.

Web hosts are slow to upgrade

[tepples]

PHP now even has closures, lamda, internal iterators

Just because the latest stable version of PHP has a feature doesn't mean that the version of PHP installed at your current web host has that feature.

Alternatives to major PHP applications

[tepples]

There have always been far better options available

Even without switching hosting companies?

There's no valid reason to use PHP today.

What free software do you recommend as an alternative to phpBB? As an alternative to MediaWiki?

Re:You shouldn't use PHP. Nobody should.

[Anonymous Coward]

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?

That's like saying PHP is better than a poke in the eye with a sharp stick. Although true, it's irrelevant to the quality argument. I'll admit I have 3 PHP installs on my many websites mainly due to them not being the core of my revenue stream. One of these days I'll expunge the last of the PHP. Anyone know of a GOOD blogging software package that does not use PHP?

Somebody set up us the BOM

[tepples]

You cannot send headers after sending any output.

Which means include files (Which are obviously often run before code that sends headers.) cannot have such extra space.

That and the whole "byte order mark" garbage (0xEF 0xBB 0xBF) that some text editors insist on inserting into UTF-8 encoded text files.

Operator IN

[tepples]

What benefit do you get from re-inventing a language feature that's already there

Because the feature to pass a PHP array as the right side of SQL operator IN isn't already there, at least not in MySQLi. I invented this once, as a function that takes a MySQLi database object and an array and returns an escaped string appropriate for use with operator IN, and reused it throughout my employer's PHP-based products.

All modern languages provide facilities for doing things the right way, so what possible motive would you have for deliberately and painstakingly doing things the wrong way?

PHP is up to 5.4, but a lot of hosting providers aren't even up to 5.3.

Re:Operator IN

[Just Some Guy]

I'd file that under "writing database libraries", which is the one place I consider it completely appropriate to handle that kind of stuff (therefore encapsulating the work so you don't have to repeat it everywhere in your code that you want to write "IN" queries). I have no problem with that.

Specific missing features in the DB interface

[tepples]

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. [...] Not "well, not usually but..." or "there are some situations where...". No there aren't.

In cases I've seen, the alleged "some situations" arise from specific missing features in "the DB interface library that everything runs through" such that the application developer ends up having to write what amounts to an extension to the library, and this extension will involve escaping. So yes, there are in fact "some situations".

Re:Specific missing features in the DB interface

[Just Some Guy]

Back to what I said elsewhere: I consider that part of "writing the DB interface library", and not something you'd be doing in daily programming. I draw the distinction that you're building an infrastructure to base other code upon, and not writing ad-hoc code for copying-and-pasting elsewhere.

Re:And

[fwoop]

Because you like pain.

bind_param() isn't designed for a loop

[tepples]

create a function that loops through an array and calls "bind param", or whatever MySQLi prepared statments use, for each value in the array.

As I understand it, $stmt->bind_param() is not designed to be called in a loop. It is a variadic function designed to be called once per call to $db->prepare(), with one string designating the type associated with each placeholder in the statement and one additional parameter passed by reference for each placeholder in the statement. If I were to try to bind one parameter at a time, the first call would raise an error that the parameter count does not match, in other words, that I didn't bind all the parameters in the first shot. From the documentation: "The number of variables and length of string types must match the parameters in the statement" (my emphasis on "number of variables").

Re:bind_param() isn't designed for a loop

[anss123]

Sorry about that. I've never used MySQLi, as you may have guessed, and that does sound awkward.

Though I did some prepared statement stuff on MySQL/MsSQL/Oracle with PHP and a wrapper lib that let me use "bind_param" for each variable. Only problems I encountered is how oracle requires params that don't have length specified to be rebound if the size increases, and of course writing SQL that works identically on three databases.

Re:bind_param() isn't designed for a loop

[tepples]

I use bind_param in lots of code and it works properly.

But do you use it in a loop, with more than one call to bind_param for a given call to prepare? That's the use case that anss123 was referring to, and though it might work with some DB drivers, it does not work with MySQLi. If MySQLi is the problem, should I just start using PDO for new pages and keep two connections open, one for things ported to PDO and one for things that haven't been?

Re:And

[colinrichardday]

That would be the correct answer to "Why should I want a dominatrix to spank me?", not "Why should I use PHP?".

Lack of fork/exec under Windows

[tepples]

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.

Re:Lack of fork/exec under Windows

[dkf]

This goes double for Windows, where pcntl_*() is not implemented and escapeshellcmd and escapeshellarg have completely incorrect behavior.

Not to detract from the main point (PHP's ability to avoid Doing Things Right at nearly every opportunity) but it turns out that it is impossible to get proper consistent behavior on Windows when starting a subprocess. The core of the problem is that the parsing of command lines into words is done by each program for itself, and there are a number of programs and shell commands that do it inconsistently. (The one you're most likely to run into is START, which has a totally retarded way of handling its first argument.) Because the trouble is baked into the whole way things work, you can't fix things. Thankfully, almost everything using the MSVC runtime or the same algorithm it implements, which means you don't have to worry about how bad it is usually, but it's still a disaster.

And it's all DOS's fault, or perhaps CP/M's; I don't know if it was a MS innovation when they wrote PCDOS. I didn't start using MSDOS until about 3.3 (ugh, I feel old) and it was already an entrenched piece of obvious lunacy then. A bad decision can persist for decades.

Re:Lack of fork/exec under Windows

[Just Some Guy]

Having zero experience with PHP on Windows, I ask this out of curiosity:

In Python, I've taken to passing arguments as a list to things like subprocess.call, bypassing the need for any kind of command line parsing. Does PHP let you do things like that, so that you run the equivalent of "system(commandname, '/z', '/o outputfilename', 'some complex! argument')"? I know that system itself doesn't directly support that, but wonder if some other facility might.

Re:Lack of fork/exec under Windows

[tepples]

PHP supports passing a list of arguments to a program in the manner you describe, but only if A. you're running on *n?x (or in a *n?x virtual machine under Windows), and B. PHP has been recompiled with the pcntl extension (which is disabled by default).

Re:Lack of fork/exec under Windows

[Just Some Guy]

Oh, OK. I saw you talking about pcntl in a thread and didn't realize that's what it was.

BTW, thanks for un-foe'ing me. :-)

Advantage of CGI

[tepples]

Doesn't using mod-cgi require all your files to be in a folder like cgi-bin?

Not necessarily. I haven't set it up myself in a while, but the recipe involves SetHandler none, AddType to give PHP a content type, and an Action for that type that points to the PHP CGI binary.

All the free hosts I've used /seemed/ to use the Apache mod

I was under the impression that executing PHP programs as the owner of the program's file required CGI, not the module. The module can execute them only as Apache, which creates permissions problems for anything that writes to the file system, such as a file upload script or an SQLite database.

Re:Advantage of CGI

[RobbieThe1st]

Couldn't you simply use groups for that? All users have a main group of "www-data", and so long as your PHP script makes sure that there's r/w group permissions, it'd be accessable as the user directly.

I'd bet that happens a fair bit - I seem to recall running into that sort of permission issue once, had to write a PHP script to change the permissions so I could overwrite it with FTP... but that was years ago(before I found ssh/scp/rsync), so...

Re:And

[MechaStreisand]

It deserves the coveted "5, Troll" mod. Everything in it is true.

If it compiles...

[maedls.at]

... ship it!

Re:And

[Bill, Shooter of Bul]

You cannot call Active Record scalable and expect people to take you seriously. It isn't. ROR is a fine choice for a front end that connects to a real backend to do the heavy lifting ( which may run Ruby sans Rails) . And to be fair, it might be okay to start with an all rails solution with a plan for what to do if the site takes off.

Re:And

[Bill, Shooter of Bul]

Drupal is terrible for a high volume site too...

MSVC command escaping

[tepples]

Thankfully, almost everything using the MSVC runtime or the same algorithm it implements, which means you don't have to worry about how bad it is usually, but it's still a disaster.

Python for Windows has correct MSVC command escaping. PHP for Windows does not, I'm told. Therefore, you still "REALLY need to switch languages."

Re:And

[Kalriath]

Great track record? This 8 year old exploit begs to differ.

Re:And

[crutchy]

if you're implying he gave up asp for php (dropping a big shit), i agree. asp kinda sounds like its related to both mambas and shit, and its owned by the biggest asshole of them all.

haven't used mod_cgid personally, but i'm sure bugs will be fixed and it will be business as usual...

...along with the usual dotslash overreaction

Re:Cm'on

[Kalriath]

Of course it's intentional. It links to a job posting for a security engineer, and the job posting clearly does not appear in every single Facebook page so that's definitely not the actual source of the page.

Re: DD-MM? WTF!

[Kalriath]

Hey arrogant twat, the rest of the civilised world writes it as DD-MM. Nobody, except Americans, thinks it should ever be MM-DD.

Re:And

[Jaxoreth]

Because you like pain.

That would be the correct answer to "Why should I want a dominatrix to spank me?", not "Why should I use PHP?".

One man's pain is another man's pastry. Especially if he's French.

Re:And

[micheas]

D7 and pressflow scale pretty well.

Out of the box it supports slave db servers for all read requests, and supports reverse proxies.

If you said D7 has a large memory footprint you would be right, but that is different form scaling.

There are several high volume sites that run on Drupal, they might be able to run on less hardware if they used something else, but being more expensive is different from being terrible.

Re:Cm'on

[Netshroud]

Facebook doesn't actually run PHP, they run a gigantic C++ binary.

Re:And

[Waccoon]

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?

Re:And

[Bill, Shooter of Bul]

If you don't have multiple masters, you haven't really scaled yet.

Re:And

[LingNoi]

> Now days I evangelize RoR

Why do evangelize anything? Just let people use what they like and stop caring if people like things you don't like. You're acting like a child.

Here we go again...

[Anonymous Coward]

I did a quick search for the term "string" in the Java bug database... Here's what I wound up with: http://search.oracle.com/search/search?search_p_main_operator=all&start=1&group=bugs.sun.com&q=string

This is 1 page I wound up with using "asp.net bug" with Google: http://threatpost.com/en_us/blogs/microsoft-release-emergency-patch-aspnet-bug-092710

Here's a list of Python bugs... http://bugs.python.org/

I would say that Ruby has bugs, but they're keeping their cards close to their chest with that one as you can't even see what they've acknowledged: http://bugs.ruby-lang.org/

C# obviously has bugs... http://msdn.microsoft.com/en-us/library/cc713578.aspx

Meet the new complainer, same as the old complainer... PHP isn't going anywhere anytime soon. Might as well get used to it. :.)

Re: DD-MM? WTF!

[fnj]

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.

Re:And

[myowntrueself]

great track record

LOL

Re:And

[ahodgson]

It's easy. Embed some (horrible insecure) code in a web page, hit refresh on your browser, and away it goes.

Re:And

[Eponymous Hero]

http://i0.kym-cdn.com/entries/icons/original/000/007/508/watch-out-we-got-a-badass-over-here-meme.png