Another Serious Security Bug on PHP 5.3.9

Contents

PHP 5.3.9 Arbitrary Remote Code Execution Vulnerability

Earlier today, the well known security expert Stefan Esser has revealed again yet another serious security bug in PHP.

This time it is a bug that allows arbitrary remote code execution. This means that it allows to run arbitrary code on the server, injected by an eventual attacker, so it can be used to cause many types of damage inside a server.

In December it was publicly disclosed a security bug named hash collision that could make the server consume too much CPU cycles just to process the parameters sent by a HTTP request.

This time the bug was found precisely in the code that was added as work around the hash collision problem. It affects the handling of the new max_input_vars option. This means that the attempt to avoid one security problem caused another problem.

This is just a reminder of something that I commented in a previous post about whether you should try new PHP versions or not. New versions, new bugs. I mean, new versions may no longer have old bugs, but they may introduce new bugs that can actually be worse. That seems to be the case.

Anyway, fortunately Stefan Esser discovered this problem and the new PHP 5.3.10 was just released.

What shall you do now?

Well, if you have already upgraded to PHP 5.3.9, you should upgrade again to 5.3.10. If you have not upgraded to 5.3.9 yet, you should still upgrade to 5.3.10 because if you are not vulnerable to this remote code execution security bug, you are vulnerable to the hash collision problem.

The remote code vulnerability problem is more serious in the sense that it allows an attacker to cause internal damage to your server. The hash collision problem may bring your server down but your servers internals would not be affected. In any case, it is better to have none of the problems, so upgrading is always the best choice.

The sooner you upgrade, the less are the chances of suffering a security attack. Do not wonder too much.

Suhosin Security versus the PHP World

Coincidentally, today the Debian Linux distribution maintainers decided to drop enabling Suhosin by default.

As it was mentioned in a previous post about the hash collision PHP vulnerability, Suhosin is a PHP extension that is meant to protect PHP installations against known and unknown PHP security bugs. It was developed by Stefan Esser, the same security expert that discovered this security bug just fixed in PHP 5.3.10.

Debian and other Linux distributions used to include Suhosin enabled by default with their PHP distributions. Now they have decided to leave Suhosin disabled by default.

Several reasons were presented for this decision, which include loss of performance, excessive memory usage, difficulty of determining if certain PHP bugs are caused by Suhosin or not, etc..

The announcement of this decision of Debian maintainers started yet another heated discussion in the PHP internals mailing list. On one side Debian maintainers and some PHP core developers do not want to deal with the consequences of adopting Suhosin as is. On the other side Stefan Esser and other developers that support his points of view claim that security is more important and the presented problems are not necessarily caused by Suhosin.

This discussion will still last a while and will probably return in the future, eventually when other PHP vulnerabilities are exposed.

The fact is that history has shown that some vulnerabilities are effectively prevented by Suhosin since many years ago, and only now PHP core developers are doing something about it just because someone else exposed such vulnerabilities to the world, just like it just happened with the PHP hash collision vulnerability.

On the other hand, the fear that the use of Suhosin may cause PHP applications to not work properly makes PHP developers worried about using an extension that may cause more application bugs than those that really exist.

This is definitely a tough call. Personally I have been trying Suhosin in my development environment since not a very long time ago. I confess that I have not given it much attention in the past because I was not aware of how many situations that the official PHP distribution does not handle well, but Suhosin addresses them since many years ago.

What I can say for now is that it works but I cannot reach to a conclusion if it is safe to use in production before I try all my Web sites code extensively. Maybe I will get back to this subject in the future.

As for the PHP development, I do not know exactly why Stefan Esser is not working more closely in the PHP core today. I know that he was a member of the PHP security team but he left after a while for reasons that I did not see disclosed publicly.

Maybe there were personal issues with other PHP security team members. Maybe there were fundamental differences between them regarding the criteria that should be followed to make PHP more secure.

Whatever are the reasons, I must admit that now I feel sad and worried for the security of PHP because we all know and reckon that Stefan Esser is such an highly qualified security expert and his security expertise and his work is not being integrated in the PHP core for whatever reasons.

Anyway, I have seen some proposals for Stefan to submit Suhosin features as RFC. I am not sure if that will help having those features proposed to the PHP core because as we all know by now, proposals often ended being voted down and those that vote them down are not required to present a valid technical reason.

This means that in practice any proposals may be boycotted just because the voter does not like the proponent, regardless of the technical merits of the proposal. This is just one flaw of the PHP proposal system that I do not know if it will ever be addressed.

As a side note, I would like to mention that I actually saw some PHP core developers complaining that today there are not many active developers to the PHP core as in the past.

Maybe it is about time that they realize that the reason many developers have excluded themselves from contributing to the PHP core is because they felt too much boycotting to their proposals, and so they do not have much motivation to contribute. I have seen this happening so many times that it is not even surprising to not see many active PHP core contributors.

Some PHP core developers are not really very diplomatic and often are very cynic towards the people that propose new PHP features. Maybe it is time for everybody to reflect on this and review their attitudes. Wrong attitudes may have bad consequences.

Anyway, back to the actual PHP security matters, I think that a good compromise is to integrate Suhosin features in PHP but make them optional, just like the use of the Suhosin extension is optional.

That way it is up to whoever installs PHP to enable such features or not, being that either at the PHP build time or at run time using php.ini options. It is not ideal to everybody, but it is probably the best compromise to please both those that like and dislike Suhosin.

Conclusion

This seems to be yet another episode of the long PHP development soap opera. Now the hot topic is about security. The PHP audience is very interested in this topic. So the world is waiting to know what will be the outcome of this episode. Meanwhile, more discussions inside and outside the PHP core developers community are expected to happen.

As a PHP developer that is paying attention to this topic, you are probably following these developments with great attention. Maybe you already have an opinion about it. In that case, feel free to post a comment telling your thoughts on this. Will Stefan Esser submit Suhosin features as RFC proposals? Will PHP core developers accept proposals to include Suhosin features and make PHP more secure? If it was up to you to decide what would you do?