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."
I finally know what PHP stands for. (Score:5, Funny)
Re: (Score:3)
I thought it meant Pointy Haired Programmers.
Re: (Score:2)
Piled High Poop more like it.
PHP Objected Oriented Programming: POOP.
Re: (Score:2)
You must be a PHP developer, probably of the team that "patched" this hole.
Actual Details... (Score:5, Informative)
Available from the source [eindbazen.net], 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.
Training wheels without the bike (Score:5, Informative)
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.
Just a little reminder (Score:3)
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 [google.nl]
RE
Re: (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 heav
Re: (Score:2)
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: (Score:3)
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
htaccess fix and shared hosting is why (Score:3)
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.)
Re: (Score:2)
also it seems that lighttpd+php-fastcgi is not vulnerable.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2, Interesting)
stable
no licensing
great track record
no licensing
flexable
no licensing
modules for everything
no licensing
false - PHP has various licensing (Score:5, Informative)
Re:And (Score:5, Interesting)
> No licensing
Wrong [php.net]
> stable
This news post is proof that's wrong.
> great track record
Wrong. [veekun.com]
> 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.)
Re: (Score:2)
God, why do you never have modpoints when you want them? This deserves so much better than '-1, Troll'.
Re: (Score:2)
Re: (Score:3)
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 (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:And (Score:5, Funny)
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...
Re: (Score:2)
Great track record? This 8 year old exploit begs to differ.
Re: (Score:2)
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: (Score:2)
Drupal is terrible for a high volume site too...
Re: (Score:2)
haven't used mod_cgid personally, but i'm sure bugs will be fixed and it will be business as usual...
Re: (Score:2)
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:You shouldn't. Nobody should. (Score:5, Interesting)
Re:You shouldn't. Nobody should. (Score:5, Insightful)
Re: (Score:3)
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: (Score:2)
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: (Score:2)
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.
Advantage of CGI (Score:2)
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: (Score:2)
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: (Score:2)
VB6 wants its argument back
Re: (Score:3)
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 decentl
Re: (Score:2)
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: (Score:2)
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: (Score:2)
FastCGI is unaffected. I've tested (not like testing this issue is hard).
Re: (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 unf
Re: (Score:2)
Re: (Score:2)
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:
to return TRUE. Instead, they got:
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. Joyou
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*.
Web hosts are slow to upgrade (Score:2)
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.
Re: (Score:2)
QBasic doesn't
Re: (Score:3)
Re: (Score:2)
Re: (Score:2, Troll)
Re:You shouldn't. Nobody should. (Score:5, Funny)
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/ [sprocket.io]
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/ [cybertiggyr.com]
No need to thank me for getting you up to speed on the latest web development techniques... but you're welcome.
Re: (Score:2)
Re: (Score:2)
http://www.webtoolkit.eu/wt [webtoolkit.eu]
Re: (Score:2)
Re: (Score:2)
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: (Score:3)
Re: (Score:2)
Alternatives to major PHP applications (Score:2)
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. 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: (Score:2)
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: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: (Score:2, Funny)
Re:You shouldn't. Nobody should. (Score:5, Informative)
Prepared statements [php.net]. 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.
Specific missing features in the DB interface (Score:2)
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: (Score:2)
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: (Score:2)
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 [python.org] 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 belo
Re: (Score:2, Insightful)
Re: (Score:2)
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 mode
Operator IN (Score:2)
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: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
Lack of fork/exec under Windows (Score:3)
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 [veekun.com] 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 d
Re: (Score:2)
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
MSVC command escaping (Score:2)
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: (Score:2, Informative)
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 inconsis
Re: (Score:2)
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: (Score:3)
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 [php.net], 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
Re: (Score:2)
Yeah, it also has this:
http://us.php.net/manual/en/pdo.prepare.php [php.net]
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: (Score:2)
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: (Score:3)
There's no need to escape things before passing them to MySQL, just use PDO (or mysqli) prepared statements.
Re: (Score:2)
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 [pineight.com]. 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 s
Re: (Score:2)
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
bind_param() isn't designed for a loop (Score:2)
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
Re: (Score:2)
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: (Score:2, Interesting)
Re: (Score:3)
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 optimiz
Re: (Score:2)
That would be the correct answer to "Why should I want a dominatrix to spank me?", not "Why should I use PHP?".
Re: (Score:3)
Re:Cm'on (Score:5, Interesting)
Re: (Score:2)
Did they not put a closing tag there just to drive us insane?> Argh!
Re:Cm'on (Score:4, Informative)
Huh, the practice is even recommended by Zend [zend.com]. Isn't PHP great, where a closing tag is a vector for bugs?
Re: (Score:2)
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.
Somebody set up us the BOM (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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: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:Microsoft Sux! (Score:5, Funny)
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
Re: (Score:2)
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
Re: (Score:2)
Unless this deficiency in mod_php has been address