PHP security from the inside

Stefan Esser is the founder of both the Hardened-PHP Project and the PHP Security Response Team (which he recently left). Federico Biancuzzi discussed with him how the PHP Security Response Team works, why he resigned from it, what features he plans to add to his own hardening patch, the interaction between Apache and PHP, the upcoming "Month of PHP bugs" initiative, and common mistakes in the design of well-known applications such as WordPress.

Could you introduce yourself?

Stefan Esser: I am an independent German security consultant and application developer. For about five years I have contributed dozens of advisories about security holes in software like CVS, Subversion, Linux, NetBSD, MySQL, PHP, Samba and even the Microsoft Xbox to the security community. Six years ago I started working with PHP and became one of its core developers. Due to my in-depth knowledge of the PHP source code, I found most of the vulnerabilities in PHP that were reported during the last years. I am the founder of the Hardened-PHP Project and the PHP Security Response Team that I recently left.

Why did you start the Hardened-PHP Project?

Stefan Esser: The Hardened-PHP Project was founded in 2004 in response to a number of security bugs I found in the PHP source code. The idea of a hardened version of PHP was actually much older, but it was never implemented until 2004.

The problem I saw with PHP was that often some new feature was hacked into it in a dirty way without thinking about the consequences for other areas of the code. Additionally, after having fixed a number of remote exploits in CVS versions of PHP before they made it to release versions, I stopped trusting the code at all. Therefore, the low-level protections like canaries, safe_unlink were implemented. A

dditionally it seemed a good idea to stop remote URL includes by completely forbidding them. The HTTP response splitting problem was also killed at the low level by stopping newlines in PHP's header() function. During the time more and more features made it into Hardened-PHP. [That is] until I was ordered by the PHP Group to rename my "fork" because of the PHP license. Because the PHP license actually contains such a paragraph the Patch was renamed into the Hardening-Patch for PHP, although I still don't get why they attack a PHP security extension in such a way. Later that year the Hardened-PHP Project became bigger, when two german security researchers from the PHP community joined the team. We started offering PHP security audits and PHP security courses. The two other team members finished their german PHP Security book and gave several PHP Security talks at various PHP conferences.

What is Suhosin?

Stefan Esser: Suhosin is the successor of the Hardening-Patch for PHP. Suhosin is a South Korean word and means something similar to "guardian angel". The idea behind Suhosin was to split the functionality of the Hardening-Patch into two parts. The Zend Engine protection, that protects the core from buffer overflows and that can only be implemented as a patch, and all the other protections that can be implemented in a PHP extension.

Suhosin contains lots of features that fix the misbehaviour of PHP that could result in security vulnerabilities. Usually these protections are transparent to the code. A lot of code had to be redone, because of the requirement that we did not want to break binary compatibility with PHP anymore and because it is a lot trickier to implement some of Suhosin's features from within an extension.

The goal was to have two independent parts that can be used alone or in combination, so that the user can decide for himself if he wants the core protection or just wants the high level protections. However, even when both parts are used, the binary compatibility with normal PHP is not broken, such that it is now possible to run third-party binary PHP extensions, like the ZendPlatform. Additionally this now allows Linux distributions to easier integrate Suhosin. And for most of them there are already official or unofficial packages available.

In short: Suhosin is now easier to use for the end user and easier for us to develop. Suhosin already contains many features like transparent cookie or session data encryption, experimental heuristic SQL injection detection, URL include blocking, mail() header injection blocking, basic variable filtering and a lot more. Many new features are planed for 2007. However we are currently working on a better documentation that explains all protections in-depth.

What plans do you have for Suhosin?

Stefan Esser: There are a bunch of features on the "to do" list for Suhosin. The development version currently contains some features not yet released to the public, like a simple heuristic to detect SQL injection attempts. It is planned that future versions of Suhosin will be able to learn behaviour patterns, like valid SQL queries, valid request parameters and to warn or block when a violation occurs. There are also plans to add mod_security style filters, with the major difference being that the filtering will be using the same parsing routines as PHP and therefore it will not be vulnerable to all the mod_security bypass tricks.

You founded the PHP Security Response Team. How does it work?

Stefan Esser: Well the real story is that when I first reported security holes in PHP there was no security@php contact, and everything had to go through the PHP group. I considered this a bad process and convinced the PHP group to create a dedicated PHP Security Response Team.

Basically, the PHP Security Response Team is nothing more than a mailinglist for a few core developers, and it receives security reports sent to security@php dot net.

There is no active manual auditing process inside PHP and I do not see how there could be one, because PHP developers are not security experts. While there is the Coverity source code scanner and there are a few people among the PHP developers that search for security holes, they only find minor things from time to time. Bigger security bugs in PHP are usually only found by third-parties or by me. However sometimes after a bug report, someone among the developers searches for similar code areas and finds similar bugs.

The other problem is that among the (maybe) 10 members of the mailing list, there are only two or three that do something like writing back to the reporters or trying to fix the code. Most of the others are just reading and giving comments from time to time. For example, saying that they do not want to have test exploits for fixed bugs in the PHP source code.