About a week or so ago, I wrote to webappsec in response to Yasuo Ohgaki (書ã‹ãªã„日記) post about some issues with PHP’s security model.
For some time, I’ve been worried about the direction of PHP. As many of you know, I helped write XMB Forum and now help write UltimaBB. XMB in particular is an old code base, and UltimaBB, a descendant from XMB. I’ve done a lot to protect that code base from attack, and luckily, we’ve been missed despite some doozy and silly security issues. After writing PHP forum software for three years now, I’ve come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort.
PHP needs a proper security architecture, and support for newbie programmers. PHP’s raison d’etre is that it is simple to pick up and make it do something useful. There needs to be a major push by the PHP Development team to take this advantage, and make it safe for the likely level of programmers – newbies. Newbies have zero chance of writing secure software unless their language is safe.
Think about Logo for a minute. Logo can do some interesting things, but it is not a commercially useful language because it cannot do much. But it is an excellent teaching language. PHP is like Logo – it’s a simple and easy way to get into serious web development. It is possible to write large applications in PHP, so it is useful at that level. But it is inherently unsafe as it can do far, far more than Logo.
There are so many ways to break PHP that it is impossible for even experienced security professionals like me to code in it securely all the time. There are nearly 4000 function calls, and many of them have unintended consequences or have been inappropriately extended by something else.
At every turn, the PHP Development Team have made truly terrible “security” choices:
- register_globals
- magic_quotes_gpc (and friends)
- PHP wrappers (see below)
- safe mode
- output, XML, LDAP, and SQL interfaces that intermingle data and query elements, which by their very nature are impossible to protect against injection attacks
All of these are broken. They are disjunct and have no security model. Some of the features, like PHP wrappers, are not well documented, and are a clear and present danger to PHP scripts and worse, they do not obey the weak “safe” mode restrictions. I bet few PHP coders are aware of them, let alone their security impacts.
http://php.net/manual/en/wrappers.php
PHP coders cannot rely upon their script running in a Unix or Windows environment, so they must code to the least common denominator. Hosters rarely upgrade to the latest PHP, even though it is safer. Even though programs could be ported to safer interfaces like PDO or the OO mysqli parameterized queries, programs cannot support this mode as it’s too rare. Even PEAR modules are hard or impossible to import in a shared environment, so favorites like PECL or ADODB which might help are not available, so programs ship with outdated and vulnerable libraries.
So why this whinge?
PHP must now mature and take on a proper security architecture, an over arching security model which prevents or limits attack surface area until the application explicitly asks for it. There can be no other way. If you look at Bugtraq, every day, 10-50 PHP applications are broken mercilessly. This cannot continue. Hosters cannot pay the price for the PHP development team’s lack of security expertise.
I wrote back to webappsec that we as security experts should offer our counsel to the PHP Development Team. The only response I received from Yasuo-ã•ã‚“. His response included an exploit of the PHP wrappers (as above) which is completely unaffected by any safe mode implementation. He also suggested I contact Rasmus Lerdorf, one of PHP’s creators who leads the PHP development team.
I e-mailed Rasmus, and although it’s the new year, I have yet to receive a reply. I get a lot of e-mail, but I make an effort to reply to all of it. I wish others would do the same – it is only polite. [ Edit: 24/1/2006 – I have a reply from Rasmus. Apparently, he saw Chris’s blog and thus this rant, and replied. ]
It is time to stop complaining. The time for forgiving PHP’s weaknesses are over – it must stop, and stop now. PHP 6.0 is still in development, and it should be so clearly more secure than anything before it, that hosters will upgrade to it, in the same way they have not upgraded to PHP 5.0.
It is time to ã„ãŸã—ã¾ã™ã€‚
Leave a Reply