Slashdot Mirror
PHP Security Expert Resigns
juct writes "PHP security holes have a name — quite often it was Stefan Esser who found and reported them. Now Esser has quit the PHP security team. He feels that his attempt to make PHP safer "from the inside" is futile. Basic security issues are not addressed sufficiently by the developers. Zeev Suraski, Zend's CTO of course disagrees and urges Stefan to work with the PHP development team instead of working against it. But given the number of remote code execution holes in PHP apps this year, Esser might have a point. And he plans to continue his quest for security holes in PHP. Only that from now on, he will publish them after reasonable time — regardless if a patch is available or not."
Update: 10/30 12:57 GMT by KD : Zeev Suraski wrote in to protest: "I'm quoted as if I 'point fingers at inexperienced developers,' and of course, there's no link to that — because it's not true! The two issues — security problems in Web apps written in PHP, and security problems in PHP itself — are two distinct issues. Nobody, including myself, is saying that there are no security problems in PHP — not unlike pretty much any other piece of software. Nobody, I think, argues the fact that there have been many more security problems at the application level, then there were at the language level. I never replied to Stefan's accusations of security problems in PHP saying 'that's bull, it's all the developers' fault,' and I have no intention to do it in the future."
First, the language is wide open for editing. It might help to be someone who not only finds bugs but fixes them.
Second, it's PHP. Add another API or something.
Isn't that an oxymoron?
There are two types of people in this world: those that categorize other people and those that don't.
On second thought I would have to agree that the majority of PHP flaws are due to unskilled programming.
just have a look
We have a large group of students, staff, and faculty that all have varying degrees of write access to a departmental Apache web server. Every few weeks someone asks why we're not giving people PHP access. Users love PHP because it's so easy; it makes them feel like they're clever programmers. But it seems like security knowledge is never imparted alongside the PHP training. People seem to think it's as benign as plain old HTML. When they ask for PHP I tell them we have a policy about not giving scripting-level access to users without good justification, and they have no idea why that applies to them since "we don't want to do any scripting; we just want to make PHP web pages".
But even leaving all that aside - it seems like every SANS newsletter has multiple announcements either about a bug in some popular bit of PHP-based software, or else in PHP in general. Until that changes, we're sticking to Perl and Python. It's funny, in a way, since the first time I saw PHP I immediately thought of the days when I was writing Active Server Pages on IIS4, because structurally it is so similar - and now we all realize the similarities on the security side (or lack thereof) as well.
#DeleteChrome
Huge problem is "default" installs - everyone knows where your sample scripts are. Delete those first thing then move/rename the active libraries.
Now, where's that Ruby book?
Most of the stuff on
Any language is only as good as the programmer using it.
I use a LAMP stack for the most part, many of the security holes in php aren't due to the language itself but the developers of the various webapps.
That being said, this requires a repost of the ol Adminspotting thang.
Choose no life. Choose no career. Choose no family.
Choose a fucking big computer, choose disk arrays the
size of washing machines, modem racks, CD-ROM writers,
and electrical coffee makers. Choose no sleep, high
caffeine and mental insurance. Choose no friends.
Choose black jeans and matching combat boots. Choose
chairs for your office in a range of fucking fabrics.
Choose SMTP and wondering why the fuck you are logged
on on a sunday morning. Choose sitting in that swivel
chair looking at mind-numbing, spirit-crushing web sites,
stuffing fucking junk food into your mouth. Choose
rotting away at the end of it all, pishing your last in
some miserable newsgroup, nothing more than an
embarassment to the selfish, fucked up lusers Gates
spawned to replace the computer-literate.
Choose your future.
Choose to sysadmin.
Shadus
It's widely acknowledged that open source programs are inherently insecure. Whether the cause is the availability of the "internal blueprints", the free-for-all repository commit access, or the rampant theft of patents, one wonders. By contrast, Microsoft's .NET platform, including the widely praised C#, doesn't have this problem. The guarding of the internal source code, the standards-adhering developers, and the rock-solid legality of its software patents gives Microsoft an advantage versus the haphazard "open source" languages like PHP and Java. One wonders if this is a harbinger of future defections in the open source language camp. Speaking as a patent lawyer, I advise all developers to switch to .NET and Microsoft's enterprise-class C#.
Here's the announcement from the source himself, via his blog. Based on that post I'd say he sounds pretty disgruntled with how his efforts towards security were received i.e. "he PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the security of PHP itself you become persona non grata"
When I looked at Zend's introduction to PHP, the first sample PHP program was Hello World, and the second was a cross-site scripting vulnerability. Right, I'm going to trust these people.
There sure are better alternatives to PHP in the OSS sector! PHP IMHO is a nice toy but nothing I would use in a commercial project.
A soon to be totally OS sollution is of course JAVA with Apache and Servlets/JSP. Just take a look at Sun's website, they have a lot of information, examples and tutorials available. Also, Java is totally plattform independent and easily installed on Windows, if that remains your development system.
Another, more recent sollution would be Ruby on Rails, which has some realy niffty features.
And no, not a dumb question at all! One hint: If you got the time, just download the OSS you are considering ang play around with it, that's probably more usefull than my dumb answer. ;-)
there is a wide choice of languages and platforms.
languages: there's java, there's python, there's perl, and there are more. each of the first three is (IMHO) a lot better than php (as I know it, up to about v. 4) for building web applications.
servers: Apache, with either mod_perl or mod_python access to the APIs is very good. Of course, there's the plenty of java web servers and ways to run those with or without Apache.
platforms: look at the Apache foundation's site for java, perl and python modules.
development environment: I prefer Eclipse, but there are a few to choose from.
Good luck,
As a PHP user, I have attempted to better the thing by reporting what I think are bugs. I can't name a single one that wasn't closed with a WONTFIX and a terse, non-thankful "that is a feature, not a bug." I honestly have zero disbelief that those same programmers would turn against Esser when he blamed the language, not the user, for the security problem.
In particular, the late static binding issue (if B extends A then A::staticFunc() ran as B::staticFunc() is ran under class A not B). It's like how it took MySQL took a decade to get stored procedures and views despite many people asking for it. Many people complain about the late static binding issue but last I knew it was still "it's a feature, not a bug."
Regardless, thanks for your work Mr. Esser...
:wq
Yeah, with Java becoming open source, its right in line for you. Learning Java as a C# programmer is a joke, the basics are 95% the same, especialy if you use java faces (though I'm a bit "meh" about that).
.NET, really (I'm primarly a C# programmer myself, so I know where you're coming from). Unless you had a MSDN Universal license with Visual Studio Team Foundation, or were already using .NET 3.0 (Workflow, Communication, etc), this might actualy give you a lot more power than what you are used to.
You pull java with eclipse, apache, strut/spring/hibernate/junit, then pull any database that hibernate supports, and you're in business.
There's a learning curve, but you won't feel like anything is missing from
Yes, bad developers produce insecure code, but let me take you on a brief trip down memory lane.
Way back when, when the Web was new, and CGI was just starting out, there was some debate as to whether C or Perl should be the language of choice for writing CGI scripts. In the end, Perl became much more widely used because it was just too damn easy to open up major security holes writing in C, because it lacked some of the features of Perl (like making it impossible to commit a buffer overrun, for example). Perl won out in early CGI precisely because a lot of the problems of CGI security were already solved because of inherent features of the language.
Now, PHP came along and billed itself (and in fact was designed) as an easy way to make secure web scripts. So, if the PHP code has bugs that impact its security in web-based applications, these things should be addressed. Otherwise, it's going to end up being supplanted by another language that is more secure and easier to use to build web apps.
Blaming the developer for security is only going to take you so far when the language the developer is using is supposed to be SPECIFICALLY DESIGNED for web applications.
The "news" is that Stefan Esser unsubscribed from the security@php.net mailing list.
5 -Stefan-Esser-quits-securityphp.net.html
Stefan Esser will continue to work on PHP security through maintaining the Hardened PHP project [1] which is a patchset to PHP which enables some low level security features into the language, as well as the suhosin extension [2] for PHP which can be used without patching PHP and "protects servers and users from known and unknown flaws in PHP applications and the PHP core".
I am personally of the "full disclosure" security mindset, so if there was indeed an issue with the response time of the "PHP Security Response Team" then some outside pressure would be a good thing.
More about this on Zeev's blog [3].
[1] http://www.hardened-php.net/
[2] http://www.hardened-php.net/suhosin.127.html
[3] http://www.suraski.net/blog/index.php?/archives/1
Rails is pretty cute. An more functional (but less "shiny") alternative is Catalyst. It's written in Perl, which means you get the benefit of over 10,000 extension libraries from the CPAN to draw upon. Perl also has some nice features that Ruby or PHP lack, like full native unicode support and automatic taint checking. It's also faster, because it's had 10 years to mature. Sadly people seem to be ignoring Perl these days, but with recent improvements it's nearly as cool as Ruby (check out "Moose").
Also, if you'd like to access a database with compound primary keys, ActiveRecord won't support that, but Catalyst's ORM (DBIx::Class) supports it fine.
Rails is good for quick apps like a wiki or a blog, but for more complicated internal applications, Catalyst is where it's at. Stop by the website, check out our advent calendar, or perhaps try the tutorial. Join us in #catalyst on irc.perl.org if you have any questions!
My other car is first.
Wow, stunningly insightful response "that's caused by inexperienced programmers". He's a clue: it doesn't matter what the origin of the problem is (other than to fix it longterm) - IT STILL NEEDS ADDRESSING. I got news for you: the concept of covering large security related cracks in code with prime bullshit is probably already patented by Microsoft.
Personally I would wonder if Essers' 'abrasive style' is not a result rather than a reason for not being listened to and if this flags up a major problem in the way PHP is coded and maintained I'm all for this move. There is no excuse for sloppiness.
So, the reaction discloses the attitude - seems Esser made the right move..
Insert
can someone explain how it is that the apperently consensus is that PHP is insecure by design, asside from just poor programming? Thank you.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
This reminds me a lot of the fundamental principle of politics:
In software, people with their feet so I bet this principle applies equally to this field.
Simon.
Anytime the tool does something that the user doesn't want it's a bug.
This applies to applications, programming languages, heck even cars if you want.
The fact is that if the user gets something they didn't want, no matter how stupidly they tried to use it, the tool still bears some of the blame. I don't care how dumb a thing the user did, there was something there that made them think they could do that and it's a bug.
With programming languages if the language allows the user to create a security hole it's the fault of the language on some level. Sure you can get stupid programmers but blaming the programmer entirely discourages the search for a better language. Yeah if I overrun my array in C it's my fault. But can it be entirely my fault when in Java that same bug wouldn't be a security exploit? Hey, if I drive my car straight off a cliff, is that my fault? Yeah. But a car with a computer failsafe driver wouldn't of gone off the cliff (hey, if two jetliners are on a collision course the computer takes over).
You can never make the perfect tool, even a big green button that will do everything you ever wanted will still have a bunch of people who didn't think to push the button. But it forces you to realize, you can never fix users but you can always fix your code.
I stole this Sig
>bugs were sometimes not correctly fixed or were re-introduced. This was often not noticed because there was no test-rig for exploits and the idea of having one was categorically rejected.
If that's accurate, and if there wasn't some unimaginable compelling reason, any security person would be unhappy.
Someone should fork PHP and do a major rewrite. Drop features like HTML embedding, introduce properly defined packages and make all functionality available in both procedural and OO fashions. Clean up the function names so they're predictable. And make some of the more dangerous functions safer.
PHP could be turned into a decent general purpose scripting language if someone would fork it. Unfortunately that means that we'd need someone who knows the codebase, has time and is fed up with the current PHP development process. Maybe we could talk Esser into it...
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Now, PHP came along and billed itself (and in fact was designed)
I call shenanigans! No way was PHP 'designed'!
Whence? Hence. Whither? Thither.
Law makers in Texas are debating a bill to enable people to own nuclear weapons and heavy artillery and to remove safety catches from guns.
"All you should need is a great big red button that says 'Fire'" said Congressman Bobby Ewing "Its ridiculous that people are prevented from using these things and having to put up with safety devices it just encourages sloppying thinking"
"By letting people launch nuclear weapons with a big red button we are making sure that everyone is aware of how to properly care for their nuclear weapon and that it is their god given right and responsibility to fire it carefully" said some bloke in a hat "I'm fed up with all the ridiculous procedures I have to go through to fire a gun, let alone blow up France just because a few bleeding heart liberals feel they need to protect stupid people in New Hampshire"
In related new Iowa has banned the use of indicators, roll cages, air bags, crumple zones and seatbelts as it gives people too much sense of security. California has banned the use of door and window locks and the use of burglar alarms as they make houses "secure by design".
Secure by design is the only type of security that really counts.
An Eye for an Eye will make the whole world blind - Gandhi
A bad worker blames their tools and a bad boss blames their workers.
..... then trips you up with anotherobviouslynamedfunction($par2, $par1). You could say it's not all PHP's fault, as the functions originate from different shared libraries, and PHP is only providing an interface to them by their original name and with something like their original syntax. But it still smacks of laziness on the PHP developers' part. Short aliases for commonly-used functions (a context-sensitive editor can always expand them for the benefit of the anal retentive), and differently-named work-alikes for functions that take their parameters in a different order than you might expect, wouldn't have hurt. Would they?
There's no denying that PHP has things wrong with it. It started out as a bastard son of Perl, tried to be a bit more n00b-friendly and tripped over its own cleverness. The beauty of Perl is its very inconsistency. The functions you use most have the shortest names, and there is no need to clutter things up with unnecessary brackets around arguments. Regular expressions, which you are going to use all the time, have a distinct syntax. Number and string data types can be interchanged with such wild abandon, there have to be separate operators for addition and string concatenation (JavaScript, I'm looking at you). There are constructs to populate arrays quickly. All things are subordinate to the goal of letting a programmer get a job done. Easy things are easy, hard things are possible. Perl is so broad-minded, it even has the Principle of Equivalence built in!
PHP lures you in, with obviously_named_function($par1, $par2)
Still, you've got two choices, I suppose. Learn to put up with the idiosyncracies or learn another language. And never forget the Principle of Equivalence; "All Means to the same End are equally valid", nor its corollary, "Means which are not equally valid serve different Ends".
Je fume. Tu fumes. Nous fûmes!
perhaps a better idea than forking PHP would be to add these desirable sections to python instead.
Then a php to python coverter, and then we could start to forget about magic_quotes and safe mode.
Would a suitable headline be "Goaded, Esser Back"?
Apologies to Douglas R. Hofstadter
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
If PGP stands for 'Pretty Good Privacy', I wonder if PHP should really stand for 'Pretty Hopeless Privacy'...
Oolite: Elite-like game. For Mac, Linux and Windows
> Bullshit
;)
As the linked article said, this is an experimental patch + hack. With DBIC, you just do find({key1 => $val1, key2 => $val2}), which is a natural extension of the simple single-key case: find({key1 => $val1}). This all works very well in practice, as opposed to the it-might-work approach of ActiveRecord. I'm not saying you shouldn't use ActiveRecord... but I wouldn't use it.
> I am hesitant to try any framework whose partisans routinely bash other frameworks.
Bashing? I said it was good. There are some places where Catalyst is better, and some places where it's not as good. In my experience, Catalyst's good points make more complex applications easier (frontend to an HR system is what I've done), whereas Rails full-stack approach is great for CRUD applications. You're allowed to like both, ya know!
> I'm used to getting this from Python; it's refreshing to see a Perl guy screaming at the wind.
These people (I'm one of them) get upset because their languages are technically better than the alternatives, but "nobody" uses them, and they're shunned for not using PHP. "Perl is so 1996, man, use PHP or Ruby now." Irritating. use Perl;
My other car is first.
Amazon has The Design of Everyday Things by Don Norman available second hand. He argues similarly. If a door has a sign that says 'push' and someone tries to pull, you can blame the user, but it would be better to design a door that invites pushing and discourages pulling. Or vice versa. abebooks.com also has some copies. It was also published as The Psychology of Everyday Things. Good read.
Loose lips lose spit.
There was an exploit for mambo some time ago, sql injection i believe, perhaps several others also, so mambo is a likely culprit.
One cannot say it was PHP directly that got the machine compromised. It was an exploit in a script written in PHP.
A box isn't going to get compromised if PHP was installed alone on the box without any scripts (at least it's very very unlikely).
Is C the direct cause of your box owned when their is an exploit in say, proftpd for example?
I mean, I could also say...
"yeah, you'd have to be mad to run sendmail on a box you don't want to get owned"
"yeah, you'd have to be mad to run proftpd on a box you don't want to get owned"
"yeah, you'd have to be mad to run bind on a box you don't want to get owned"
"yeah, you'd have to be mad to run a linux kernel on a box you don't want to get owned"
These applications have all had their problems in the past, maybe some still have problems, but overall
they get fixed when new exploits/bugs are discovered.
I'm not quite sure why, but a lot of people/webmasters/admins do not check for updates to the 3rd party php scripts
they have installed, they just install them once and leave them running... Then they wonder why their box was compromised
due to them running out of date software.
You wouldn't leave your windows machine unpatched and never check for updates, would you?
This would of course be why Java, probably the most widely used commercial language on the planet, has had so many massive security issues......
Oh wait, it hasn't has it. It is also why Apache had so many more security issues than IIS4 because Apache was used... oh hang on that one doesn't work either.
Maybe if you used you mouth rather than your butt for speaking you might make more sense.
An Eye for an Eye will make the whole world blind - Gandhi
Any time I see a Rails vs. Django comparison, which is quite often, half of the Python users have their nose hiked 90 degrees into the air. They're maybe half as bad as the Lisp community (which rates a full centidijkstra in arrogance). I don't represent this as being scientific fact, but it is exactly what I have observed.
The classic example is the database access API (or maybe it's specific to mysql, I forgot). It doesn't support bound parameters. Use of placeholders ('?') and bound parameters is a must for secure SQL, but PHP doesn't support them, and instead requires the developer to jump through hoops escaping user-supplied data which must be passed as literals into the SQL statement.
Although it might be possible to make a secure SQL-using PHP script, the odds seem against it. Everytime I look at the changelogs of popular PHP applications, I see new fixes for SQL injection vulnerabilities. Clearly programmers don't always remember to escape those literals!
Lack of placeholders also affects the database's ability to cache prepared statements. Statements full of literals are different each time through the loop, whereas parameterised statements can be executed more quickly.
All in all, PHP strikes me as a toy language and not well suited to writing secure systems.
PHP has many eyes, yes. That's one of it's great advantages. But it also is prone to security issues. Any grown up PHP dev will admit that flat out. Fault tolerance, Reverse proxy, URL dispatching, close ties with the Framework/CMS team, basic brain functions when configging Apache and the underlyin OS, common ground standards of secured client server communication and some other details are part of the regular toolkit of PHP developers to deal with these issues. The versatility of PHP comes with that tradeoff, one has to deal with it, period.
We suffer more in our imagination than in reality. - Seneca
That's because you're not opposing the 2 real things here. Unnoticed hackers abusing the bugs without nones knowledge versus letting everyone know where the bug is and that it exists in the first place.
Quite often a quick-patch to slam a door is only a few lines. It may not be compatible with everything in the system, but it will do for some people. These patches never make it into the php right now and your ass is still uncovered for the skilled. It's interesting that you feel more comfortable with less information and the illusion that your application is safe.
I think he's doing the right thing and once the storm passes everyone will agree that his move was the right one. We'll have less secret bugs and more patches for the open ones than we do right now.
Everyone who has money inside the public php based applications will benefit after a year, although their sloppy code may not make them benefit from it tomorrow.
You have to know your enemy, otherwise we're stuck on a system similar to windows where unknown shite lurks around and none even not the creators have any kind of idea where that last bastard worm came from.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
Yes it does. It's a question of design, the design of the programming language, of its documentations and of its library can make security holes much harder to create.
When it actually becomes harder to do the wrong thing than to do the "right" thing, creating security holes becomes the fault of the user. When it's much harder to do the "right" thing than the "wrong" one, and most documentations suggest the "wrong" thing, then it's completely the fault of the language.
Most PHP issues are the latter.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
this exact story shows why disclosure continues to be necessary. Esser failed especially at getting PHP programmers to make PHP more secure. They summarily resited any of his effortsand suggestions, and in the end he felt isolated and antagonized. "the moment you criticize the security of PHP itself you become persona non grata" he wrote in his blog
The sorry fact is that those assholes *have* to be forced. You *have* to beat sense into them, since apparently they are not accesiible to reason.
So full disclosure continues to be the way to go.
Heise has more details on the issue.
Could someone explain to me why I can never EVER see the first comment? I have to infer what was said from the second comment. In this case, I presume the first poster said that PHP was the best programming language. I am using the newfangled AJAX-y comment thread expandomatic, but there's no button to click to see the first comment if it's been modded down.
The only Rails guy I see routinely mouthing off is DHH. Most of his invective (that I've read) is aimed at Java, though, which is a mitigating factor. J2EE is easy to bash because you'll be right most of the time.
You have to know your programming language, and I don't just mean syntax. Know what it aims are. There are always compromises to be made in programming. Some languages (eg. C/C++) allow low level platform dependent control, some (eg. Java) no pointers (use GC's) and cross platform, others (eg. Perl, PHP) allow RAD, massive library support.
When I first started dabbling in PHP I recall it being billed as an easy language to learn so non-hardcore programmers could ease into web design. I've seen excellent graphic artists get by with enough PHP to get the job done. They are pushing content and rely on popular CMS's to take care of the scary stuff.
PHP could probably use improvement, what can't, but people harp on about it needing typed variables etc, to me that raises the bar of entry and goes against some of PHP's strengths. Consider for a moment that not everyone has a mindset for typed variables and that their is power with untyped. There are other languages if this feature is a show stopper for you.
If there are bugs in CMS's (or whatever) written in PHP, then those (professional) programmers made errors. You really don't ... go blaming your tools. You chose them.
Programming has always been been about finding better ways of dealing with gotchas in all programming languages, whether they be memory leaks or catching untyped variable issues.
Have a look at the PEAR library sometime, specifically MDB2. It does what you're looking for in PHP.
C (still) makes it easy to create buffer overrun exploits in your apps, so is this the fault of C or the fault of the incompetent programmer using it? PHP is a tool, like a hammer. You wouldn't blame the hammer if you were careless and whacked yourself in the thumb, would you?
All movements for social change begin as missions, evolve into businesses, and end up as rackets.
You mean you would never use PHP in commercial projects like Flickr, Digg, Yahoo!, del.icio.us, imageshack, hotscripts, or other sites of that caliber, right? Well those websites ALL use PHP. Get your head out of the "let's bash the programming language itself instead of just criticizing the bad programmers who make it look bad" club. There are lots of ways to write insecure code, sure. But there are also lots of ways to write secure, efficient, well-designed code that can handle hundreds of thousands (even millions) of requests each day, and these sites prove it.
The reason you can quickly find so much insecure code is just a side effect of the low barrier to entry. PHP is one of the easiest to learn programming languages I know of, and because of that, you have people writing code that have never programmed before in their life. Of course their code is going to be shitty and insecure - they haven't been taught better. It is possible to write insecure code with any almost any language, so don't bash the whole language overall. It's not a bad programming language just because it doesn't hold your hand or prevent you from shooting yourself in the foot.
Third(ed?). I use some C# at work (C++ is the normal, everyday language), and it's remarkably similar to using Java, especially when you don't use any of the more esoteric features.
It's obviously been a very long time since you've coded in PHP. The native PDO layer in PHP 5 supports bound parameters for all database drivers, and there are numerous other data abstraction layers that support this which have been around even longer.
Just because all these "popular PHP applications" you mention (care to cite examples?) don't follow good programming practice doesn't mean the language itself is flawed. PHP can't force someone to write good code.
Yes, SQL injection is not a language issue per se. It's a primarily problem of miseducation and the bad habit it forms. You learn string manipulation before you learn database access, and therein lies the source of the problem.
But...
There is something that the language people can do to stop it, not by changign the language, but by changing the standard libraries. If there was no library API which handed an abritrary string to SQL interpreter for one step parsing and execution, it would discourage the practices that make SQL injection possible.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
boohoo, welcome to system administration. It's not an easy job and assholes like you won't change that fact, no matter how much you whine. Who gives a flying fuck how much of a PITA it is, it's part of administering a system. Changing the oil in your car suck, putting gas in it sucks, why should a computer be any different? Even more so since it's a hell of a lot more complex system.
If I am a web app developer, sure something might be easy to use, but who gets blamed if security is breached - me.
:-)
Why would I want to use a language whose governing body decides that it's not worth fixing architectural security problems and leaves the burden to me as a developer? I have enough to worry about with deadlines, bureaucracy, Microsoft, the RIAA, RSI, IRS, etc.
Sure you take the good with the bad with any programming language, but I think they might be shooting themselves in the foot if the outgoing security guy's statements are accurate.
Oh yea, it took them 5 mayor versions to set up reasonable database access, obviously PHP is the pinnacle of design and security.