I don't think you have to worry about performance being affected just by chance. The problem is with intentional attacks.
They say "this happens even before any PHP code starts being executed", does that mean the script will not time out as normal php script usually do?
Hm, interesting. This exploit basically involves turning a typically O(n) operation into an O(nē) operation, where n is the number of HTTP request variables. That can get pretty hairy when n is very large, and it's quite likely that the timeout system will only come into effect after the PHP script is started. Shared hosts are perhaps most at risk, because the larger number of sites is a larger number of targets.
I think the vulnerability issue depends on the server or how the code is written
The problem is not when hash values collide, the problem is when there is a large number of entries and the computer has to compare the new hash value to every existing hash value. Basicly by simply creating too large hash tables and the apache process (or computer) hangs and crashes. And this is a secuirty vulnerability because an attacker can do this by simply making requests with a large number of request variables.
No no no no. Listen to a guy who's done courses in computer security and data structures, and who knows exactly how hash tables work (me). Because I am going to explain exactly how it works, hopefully in a way that is understandable.
A hash table is a great data structure. It basically consists of a large number of linked lists, called "buckets". The idea is to perform a one-way function called a hash function, which takes candidate data as input and gives a number as output. We take that number modulo the number of buckets, and use the result to decide which bucket to put the data in.
For example, suppose you want to add "Hello" to an empty hash table with 16 buckets, using the hash function "number each letter, and add them together". H is the 8th letter in the alphabet, E is the 5th and so on, so the hash value of "Hello" would be 8 + 5 + 12 + 12 + 15 = 52. Since there are 16 buckets (numbered from 0 to 15), we divide 52 by 16 and get the remainder: 4. "Hello" is therefore added to bucket number 4.
The idea is that the hash function should be fast, and should distribute its outputs roughly evenly, so that the data is assigned to buckets in a sensible way. For this, my hash function in the example above is really awful. There are much better hash functions available. If a good hash function is used, searching for data is really fast: you simply hash the input and then look in the bucket, rather than checking all buckets in turn. More buckets means faster access, at the cost of a very small amount of memory used per bucket.
An important property of hash functions for security reasons is the following: it should be computationally infeasible to find any two different inputs x and y such that hash(x) = hash(y). This property is known as strong collision resistance. As it happens, if there is a method to compute such a pair, there is generally a similar method to find lots of different inputs with the same hash.
So, what does all this have to do with the topic? Well, it seems that the hash function used for the hash table which stores the HTTP request variables has been found not to have this strong collision resistance property. This is problematic because an attacker can easily send lots of different request variables, all of which have data which hashes to the same thing. Two things with the same hash are added to the same bucket, so rather than the hash table's usual hundred or so buckets, all data is crammed into the same one. This reduces the efficient hash table to one not so efficient linked list, which in turn will cause the server to take an excessively long time to process every such malicious request.
there is a lot of FUD on this, sometimes phpclasses disappoint me so much, yes there is a problem that needs to be addressed, but the title is so exaggerated, we have a lot of possibilities to keep our servers safe from that kind of ddos (and yes that is a type of ddos), Lemos is a writter and should stop trying to be a developer or a journalist until he is ready to be serious about that.