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

Comments

he just left a mailing list...

[aaronwormus]

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

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/15 -Stefan-Esser-quits-securityphp.net.html

Re:Not up-to-date on PHP security . . .

[dysfunct]

I actually do a bunch of security consulting for PHP based stuff. A great deal of the issues stems from the very beginning of the PHP language itself. Being designed to be as easy as possible without regard to security has kind of made it the Microsoft of scripting langages. They have not built on insecure code, but rather entire concepts that are inherently insecure (fopen() wrappers that open nearly every data connection they're fed, register globals, SQL string concatenation) and have even for a long time endorsed and taught users those concept.

Instead of changing concepts midway through they have added security layers and APIs that need to be *explicitly* set - meaning that like Windows (was?) they have a policy of being open per default and having to be explicitly made secure, instead of closed by default and enabling only what you need.

That's what I think Stefan Esser means when he says "safer from the inside". Many things in PHP are inherently flawed and can only be remedied through changes in concept and nothing else.

Add to that stuff like $GLOBALS overwrite (more details here) that are/were essentially a WONTFIX. No wonder Essner is getting frustrated.

Re:Lemme guess... MySQL is also the best database?

[Anonymous Coward]

I don't think PHP was designed as an easy way to make secure web scripts. Maybe easy, but certainly not secure.

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.

Re:As a PHP user....

[Splab]

Amen to that.

I had a fun one where one of my scripts would cause a segmentationfault, after hours of debug I found that they don't check the return from malloc when you call a function, so a very deep recursive function will result in a segfault. Now I had the problem with an actual system with 1000s of lines, so I made the simplest possible:

function foo($a){
    echo $a . "\n";
    foo($a+1);
}
foo(1);

Now this is of course a stupid function since it will never terminate, but it illustrates the point of the segmentation fault, I don't mind that deep recursive functions can exhaust the memory available, but I do mind the way the system handles the problem.

The bug got rejected, and that was that. I don't do PHP anymore, so I don't really care about that any more.

Re:Not up-to-date on PHP security . . .

[kestasjk]

I've written lots of PHP code in my spare time, and have written an article on creating "rootkits" to covertly inject into PHP scripts (phpBB2 in particular), so I thought I'd chime in. This'll probably be a long post but hopefully it'll give people some things to look out for.

Here are the most common security problems you run into in PHP:

• magic_quotes: This adds slashes to all input so that you don't have to sanitize it before it gets inserted into SQL. The problem is that developers write their code with magic_quotes on, but don't realize that it's often turned off elsewhere, which leads to gaping holes.
• register_globals: Variables can be placed directly into the global namespace. If you don't explicitly set all variables before using them anything can be injected into them, which brings me on to:
• Only critical errors are reported: If you use a variable which isn't set it'll just return null, with no error (unless you specifically turn up the error_reporting level). This means that someone who isn't familiar with the problem won't know that a variable in their script can be written to by anyone until it's being exploited, functions which you would expect to return an error and halt the script if they fail can carry on without giving any indication of failure.
• fopen_urls: By default you can include scripts hosted on other websites! This often makes remote PHP execution, which would otherwise require eval(), much easier.
  Who would have thought "<?php include($var.'/include.php'); ?>" will run any PHP on any server, anyhere? (The attack in the article above leveraged entry using this, coupled with register_globals.)
• Inconsistencies: What one function does can never be applied to what another function does; you can never assume anything with the PHP library and always have to keep a browser window with the PHP manual handy. Using a function without carefully reading up what it does, even when it's very similar to another function you're familiar with, is asking for trouble in PHP.
  The same goes for just about everything; are you checking whether some input equals some harmless number before passing it on to a SQL query or the browser? Don't forget that (5 == "5 UNION SELECT secret FROM ..."), null == 0 == "" == false, "a" == 4 == true; generally you just have to be on your toes.
• Input checking is difficult: Do you want htmlentities() or htmlspecialchars() ? Have you remembered to strip_slashes() if magic_quotes is on? Remember the user can input arrays too, are you checking that the input isn't an array? Have you remembered to escape queries with mysql_real_escape_string() ? mysql_escape_string() doesn't account for the character set being used, and so isn't good enough, trying to escape input for yourself is also dangerous. What about null bytes? Remember that the user can input binary data; PHP allows null bytes, and will add a slash to them, but when you send a string with null bytes to some functions, but not others, the null bytes will be silently dropped leaving only slashes.
  To check input in PHP you have to be absolutely rigorous and take no half measures, people who aren't aware of the dangers don't stand a chance.

To be honest I'm a big fan of PHP, it's very flexible and lets you develop very quickly and easily; if you have the knowledge and self discipline it's an excellent language. But allowing fast, easy development at the cost of security is insane for a server-side web scripting language!
I was hoping that PHP6 was all about doing a 180 degree turn on security, but this article doesn't bode well..

Re:Lemme guess... MySQL is also the best database?

[tobiasly]

The classic example is the database access API (or maybe it's specific to mysql, I forgot). It doesn't support bound parameters.

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.