PHP Vulnerability May Halt Millions of Servers

Contents

What is the Hash Collision Vulnerability?

Arrays are very popular data types in PHP and any other scripting languages. These are data types that allow you to store a variable number of entries of any type. You can store as many entries in array as you want. This is the main problem of a vulnerability known as Hash Collision.

In PHP and several other languages used to implement Web applications, arrays are used to store the values of request variables such as $_GET, $_POST, $COOKIE, etc.. IF you receive a request with a large number of request values, until recent versions PHP may run into trouble.

Let me explain superficially what is the problem. The PHP runtime engine that implemented is in C reads the HTTP request data and builds arrays to store request variables. This happens even before any PHP code starts being executed.

In C and other languages, arrays are implemented as data structures called hash tables. In simplistic terms, hash tables are arrays of linked lists of entries. These arrays have a fixed size.

Every time you want to add a new entry to an hash table you need to compute an hash value for the new array entry key. That hash value is an integer value that determines into which linked list the new array entry will be added.

Once the hash table code determines into which linked list the new entry belongs, it determines if there is already an entry with the same array key in that linked list. If there is no entry with the same key value, the new array entry value is added to the linked list. Otherwise, the new entry value will replace the old entry with the same key.

This is a process that it is reasonably fast if the number of entries in the array is relatively small. However, if the array has a very large number of entries the performance of inserting new entries starts degrading.

This problem can be seriously aggravated if the values of the keys to be added in the array have the same hash value, meaning they will be added to the same linked list.

What some security researchers have found is a way to easily determine a large number of arrays keys that can be used to craft an HTTP request with many request variables (GET, POST, COOKIE, etc..) that can make PHP take hours or maybe more to handle a single HTTP request just by making PHP consume all the CPU it gets to build the request variable arrays.

This means that with even a relatively small number of requests an attacker may make PHP consume all the CPU it gets until the machine practically halts, unless something kills the affected PHP processes.

As mentioned, other languages are also affected by this problem because they use similar hash table algorithms. The matter of PHP is actually worse because PHP is an extremely popular Web programming language. According to the researchers, 77% of the Web servers run PHP.

Despite this explanation is already very technical, it is still a bit simplistic. If you want to know more about the low level details, you may want to watch this video of a conference on which the security researchers have presented the vulnerability.

Play Video

What You Can do to Prevent eventual Attacks?

This is not a new vulnerability. As a matter of fact it was presented already a long time ago in 2003. By then it seems that only Perl and cruby developers addressed the matter. Most other language developers did not take care of the matter, including PHP. So this is basically a rehash of an old problem.

This time the security researchers mentioned above contacted several language developers on November 1st, 2011. Not all language developers decided to give a prompt response. The response of PHP developers came in form of a patch to PHP 5.3.9 RC 4 and PHP 5.4.0 RC 4 that adds a new configuration option in php.ini named max_input_vars .

The max_input_vars option limits the number of request variables that PHP will accept. This means that if your server gets a HTTP request with more than a given number of GET, POST, COOKIE, etc. variables, the values are ignored.

It really does not avoid the whole problem of hash collisions but at least minimizes the bad consequences of an eventual attack. The default value of the max_input_vars option is 1000, but once you upgrade to PHP 5.3.9 which was just released, or PHP 5.4.0 that is expected to be released in a few weeks, I recommend that you lower this option value further, as most Web applications never need to handle so many request variables.

Shall I Upgrade my installed PHP version?

Well the first thing you need to consider is what kind of Web hosting do you use. If you are on shared Web hosting you will not be able to upgrade at all. It is up to your Web hosting company to do that.

Usually Web hosting companies monitor the load of their Web servers. If customer are consuming too much resources with their site scripts, they usually suspend their sites. So if your site is attacked, your Web server company may end up suspending your site even though it is not a fault in your scripts. In that case be ready to tell them about this vulnerability, so they upgrade PHP installation.

If you are on a Virtual Private Server (VPS), which some people confuse it with cloud hosting, usually VPS software monitors the server load automatically and suspend virtual servers instance that are consuming too much CPU, to not cause harm to customers sharing the same physical server.

Usually in VPS servers you have access to the machine root/administrator user, and so you can upgrade your PHP installation by yourself.

The same goes for dedicated servers, except that on dedicated servers it is up to you to monitor the server load. So if you have a dedicated server that is attacked and you are not monitoring it, you may end up leaving the server frying the CPU until it burns or otherwise stops working.

So, basically it is better that you act in advance and upgrade your PHP installation sooner rather than later.

What if I Cannot Upgrade my installed PHP Version?

Many sites run on servers on which the administrators only pre-built packages of PHP and other programs provided by the vendors of the distribution of Linux or other operating system you run on the server machine.

If you are using a recent OS version that is still supported by the distribution vendor, maybe it is a matter of days or weeks until a patched PHP version is made available by them, if they have not made it available already.

Although I am aware of this problem since X-mas when PHP was patched, I decided to wait until PHP 5.3.9 final version was made available to write this article. Despite many people knew of the vulnerability at least since then, it would not be helpful to spread the panic and talk more widely about this issue until a final official PHP version was released.

Now that PHP 5.3.9 is available, everybody that is responsible for Web servers should upgrade their PHP version. If your distribution vendor did not provide a patched version, you can always demand a fixed version now, especially if you are paying for support.

If that will take some time to happen or if for some reason you need to run an old PHP version that is no longer supported by your vendor, you still have probably one solution.

Protect your PHP installation with the Suhosin extension

In 2004, Stefan Esser, a security especialist that was responsible for finding and fixing many security bugs in PHP has developed a PHP extension named Suhosin. Stefan is an outstanding security specialist for which PHP is very fortunate to have his expertise in service of a more secure PHP implementation.

Suhosin is a sophisticated extension that can do many things to protect from eventual security exploits that many developers did not anticipate.

It is not surprising that even in 2004 Stefan was very well aware of the potential harm that an excessive number of request variables could do to PHP. That is precisely why that among many other options, Suhosin has the option max_vars which does what max_input_vars can do now with PHP 5.3.9.

So if for some reason you are using an old PHP version and cannot upgrade, you may want to consider using Suhosin. I confess that I have not tried it myself, so I am not certain if it will work well with all past PHP versions you may be using. But I think it is worth trying. In the worst case, you may want to try contacting Stefan and hire him to provide consulting in case you have difficulties.

Conclusion

It should be obvious for all developers that security issues should be taken very seriously and with urgency.

Unfortunately many developers are not very well educated when it comes to security matters. Even those that have reasonable experience in terms of security, may still escape one security problem here and there. Nobody is aware of everything. So more security is never enough.

In this case, the problems that hash collisions may cause to your servers may not be your fault because the issues are in the language implementation. However, it is the responsibility of the people in charge of the servers to do the necessary upgrades. So, if you were not aware of this problem, now that you were made aware it is up to you to take the necessary measures.

Feel free to post a comment if you doubts or disagree of any points in this article.