Slashdot Mirror

The PHP developers didn't find these bugs, Stefan Esser did. (see http://php-security.org/)

The fact that one of the bugs still remains from his original /2007/ Month of PHP Bugs shows that the PHP developers are clearly not doing a thorough job.

Don't be daft, PHP 5 is a solid language and it doesn't take much to learn how to write secure code. If you view it from a rookies point of view it could be dangerous, but that doesn't magically make the language crap in the hands of more experienced developers.

Don't be daft! PHP is a poor language, I needed unsigned ints and native utf8 string handling 8 years ago. My problem is that much as I malign PHP and have tried all the alternatives, I've not really found anything better.

But the developers aren't really helping at this point. Why they can't sanely rename the inconsistent global functions and have a secondary alias table for backwards compat I'll never know.

My question would be concerning the sensitivity of the data that is to be presented. Are we talking about sensitive customer information (i.e. ssn's) or a private area (i.e. members only section) or is security not a concern at all (i.e. personal blog)?

PHP has some serious security flaws http://www.php-security.org/ That would make it inappropriate to use for the first case, but fine for anything else. It appears that Ruby security flaws are not as well documented, probably since it's a newer language. However, I also doubt that it would be appropriate for the first case. Simply based on the fact I don't see any financial sites running on either platform.

O RLY?

http://www.php-security.org/

But yes, you are correct to a large extent. VB, PHP and Python are all the same kind of languages that are horrible kludges with no real coherence and at the same time easy to do "something" in, (but hard to do anything real in) and all of them are sadly recommended over and over again to newbies. Which would be fine if it wasn't for the fact that their code goes live now and then...

Most of the Month of X Bug websites seen recently already did that stuff and nothing happened.

This one : http://www.php-security.org/ was even done by an ex-member of the PHP security team because they weren't taking him seriously.

Windows is a twisty maze of passages, all alike, all leaking information.
Root/Administrator is a design flaw.
All the platforms you mention have holes in them.

And PHP is a crock, steer well clear. See http://www.php-security.org/

I have just analysed the last month's script kiddie attacks on my web server. 71% of them were to php-related URLs. When I first went through this exercise some years ago, the overwhelming majority of attacks were URLs related to IIS. The significance of this change cannot be overestimated.

Yes, a lot of the problems are sloppy coding, but too many are in the PHP core. How many web pages use the PHP-array-specific query-string
    ?foo[]=bar
- not many, you might think. How many use a PHP nested array
    ?foo[][][][][]=bar
- quite an unusual structure, you might agree.

The real stinger is that PHP will let this array be as deep as an attacker likes - and it's the same for a POST as for a query string, so there's no practical limit. An attacker can exhaust the space available for the stack, with several adverse consequences. This bug has a lot in common with the gravest bugs in PHP's history, in that it is a mistake in PHP's input processing: in this case, PHP trusts the sanity of user input. According to MOPB, Zend's attitude to this bug is "won't fix".

The arrogance of this attitude is breathtaking. PHP is now the most insecure package on my internet server, probably surpassing the old BIND 8 in the frequency and gravity of its exploitable bugs. I sincerely hope that Zend will get its act together and make security their number one priority. The predominance of PHP on the web is not theirs as of right - if they do not act, then either their product will be forked, or an alternative will take its place.

The nested array bug is described here:
http://www.php-security.org/MOPB/MOPB-03-2007.html

Because the PHP developers do not want to fix this anymore because it creates problems for companies providing closed source PHP extensions the only potential workaround is to manually change the size of the reference counter in your own PHP. However if you do so you have to recompile all your PHP extensions and cannot use closed source PHP extensions anymore.

I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more, which leads to improper and I even dare to say incompetent handling of reports and fixes (many of which simply get applied somewhere down the road without proper announcement or mentioning anywhere in the CHANGELOG) as well as seemingly ignorance regarding more complex vulns that are just as relevant as the glaringly obvious ones but simply not as mass-exploitable by script kiddies.

And *this* is the big problem that PHP is facing today regarding enterprise support. Maybe Jon Doe's blog installation is not as mass-exploitable by a script kiddie any more as it used to be some years ago, yet Big Company's CMS is still vulnerable to complex attacks by an experienced attacker who might use published attacks that security experts know about, yet end users do not.

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.

The "news" is that Stefan Esser unsubscribed from the security@php.net mailing list.

That may be how Suraski is describing it, but if you read you'll find a slightly different story.

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"

While I consider the URL in the article not containing
any news the content of the following URL which is
linked from within the comments was news to me

http://blog.php-security.org/archives/49-Google-Re quest-Forgeries.html

I still think it's common sense to let someone know about a problem before you announce it to the world.

Sadly, even some who call themselves security experts are more interested in attention than ethics:

http://blog.php-security.org/archives/11-You-get-w hat-you-pay-for.html

Who do we hold accountable for their actions and when? I don't think it's an easy answer.

Chris Shiflett should just ignore him and do what he needs to do to get it right.

Chris Shiflett just got busted fiddling with the Wikipedia entry for PHP, adding a plug for his book and removing information about the Hardened PHP Project, of which Stefan is the founder. It should also be noted that the Hardened PHP Project is a competitor to Chris Shifflet's business.

The more I hear about these two, the more I dislike Chris Shiflett. He seems like a marketing guy who ignores real security problems. Stefan, on the other hand, seems like an immature, but ultimately well-meaning geek who does care about security. I know which one I think is pathetic, and it ain't Stefan.

What are the credentials of Chris Shiflett? He's widely touted as a "PHP security expert", but Stefan Esser has a beef with him, and claims that this book contains serious flaws and misunderstandings.

I understand that people in the public eye like book authors are vulnerable to any crank that comes their way, but the problems that Stefan has highlighted do seem to point to a severe credibility problem, and Stefan, while prone to flaming, certainly knows what he is talking about.

In the interests of fairness, you should also read Chris Shiflett's response.

What are the credentials of Chris Shiflett? He's widely touted as a "PHP security expert", but Stefan Esser has a beef with him, and claims that this book contains serious flaws and misunderstandings.

I understand that people in the public eye like book authors are vulnerable to any crank that comes their way, but the problems that Stefan has highlighted do seem to point to a severe credibility problem, and Stefan, while prone to flaming, certainly knows what he is talking about.

In the interests of fairness, you should also read Chris Shiflett's response.