Application vulnerability due to Non Random Hash Functions

Question

Below excerpt is from an article that explains possibility of Denial Of Service(DoS) attack because of non random hash functions used in Hash Data Structures.

Answer 1

Java HashMap/HashTable can do the 'resize' operation when the filled entry reach threshold. It's hard to say that there have an fixed bucket HashMap waiting for you. Because of the operation for selecting bucket have two steps: one is take hash value of specified key; another primary step is remainder operation with total bucket size(the size has being changed by 'resize').

Answer 2

The simplest solution is to upgrade to a fixed version of tomcat. However, I suspect you want to know the details of what the tomcat people would need to change.

This attack works by exploiting a common implementation detail of hash data structures - using linked lists to hold all the values whose hash is the same. Adding values to this linked list is inefficient as the size of the list gets large. An attacker can create a list of values that are known to generate colliding hashes, forcing this inefficient behavior. In order to protect against this, you have a few options:

• Prevent collisions - prevent the attacker from generating colliding values by having some (pseudo) random factor in your hash function. Perl has done this for a long time.

• Use something besides linked lists for your buckets - the attack works because inserting N items into a linked list has N^2 growth. If you use a balanced tree or some other structure that has N logN growth when inserting, the problem should be mitigated. This may sacrifice some best/average case performance in order to limit how bad the worse case is.

Answer 3

Here's some python code to generate those keys... Haven't tested it yet, but would be interested to get feedback on it:

#!/usr/bin/python
import sys
alphabet = ["Aa","BB"]

def func(str, length):
                global alphabet
                if(length != 0):
                                for x in alphabet:
                                                new_str = str+x
                                                func(new_str, length-1)
                else:
                                sys.stdout.write(str+"=&")


for x in range(1,16):
        func("",x)

Answer 4

Understanding Attack Vector

How HashMaps work

Say a comment form on a blog accepts the parameters – first_name, last_name, comment – as post parameters. Internally, Tomcat stores these parameters as a HashMap.

The logical structure of this HashMap is like this -

"first_name" --> "Sripathi"
"last_name" --> "Krishnan"
"comment" ---> "DoS using poor Hashes"

But the physical structure is different. The keys are first converted into a hashCode, and then the hashCode is converted into an array index.

The ideal physical structure thus becomes -

0 --> "Sripathi"
1 --> "Krishnan"
2 --> "DoS using poor Hashes"

But the possible keys are infinite. So at some point, two keys will have the same hash code. This becomes a hash collision.

With collisions, the physical structure becomes :

0 --> "Sripathi", "Krishnan"
1 --> Empty
2 --> "DoS using poor hashes"

Hash Collisions and impact on performance

When you have hash collisions, inserting a new entry means iterating over all the elements in a single hash "bucket" sequentially just to find out if it already exists in the map. Inserting one element can approach O(n) complexity if all elements hash to the same value. Inserting n elements in this worst case makes it O(n*n) complexity.

In short : If you insert thousands of keys that have the same hashCode, the server will require a lot of CPU cycles.

How do you generate keys with the same Hash?

In Java, "Aa" and "BB" have the same hash code.

Because of a property called "Equivalent Substrings", we can generate several other strings with the same hashcode, just by starting with these 2 strings.

First Iteration : "AAAA", "AABb", "BbAA", "BbBb" have the same hash code

Now, we have 4 strings with the same hash code. We can permute them to generate 16 strings that will have the same hash code. For example :

"AaAaAaAa", "AaAaBBBB", "AaAaAaBB", "AaAaBBAa",
"BBBBAaAa", "BBBBBBBB", "BBBBAaBB", "BBBBBBAa",
"AaBBAaAa", "AaBBBBBB", "AaBBAaBB", "AaBBBBAa",
"BBAaAaAa", "BBAaBBBB", "BBAaAaBB", "BBAaBBAa",

All these 16 strings have the same hash code.

You can now take these 16 strings, and generate 256 strings that have the same hashcode.

In short : It is very easy to generate a large set of strings that will have the exact hash code.

How do you attack the server?

1. Create thousands of string that have the same hash code (see above)
2. Construct a POST request like this - AaAa=&AaBB=&BBAa=&BBBB= ....
3. Submit the form
4. Repeat in a loop, and create several threads so that all server resources are used up

Because this is just a POST request, an attacker can also use innocent browsers to attack a server. Just find a website with a cross site scripting vulnerability, embed code to make a POST request, and then use social engineering to spread the link to as many users as you can.

Prevention

In general, the underlying platform cannot fix this. This is considered to be a application framework problem. In other words, Tomcat has to fix this, not Oracle/Sun.

Possible fixes include :

1. Restrict the number of POST parameters - Tomcat 6.0.35+ has a new parameter maxParameterCount. The default value is 10,000. The lower the better, as long as it does not break your functionality.

2. Restrict the size of the POST request - For the attack to work, the Payload has to be huge. The default POST allowed by Tomcat is 2MB. Reducing this to say 200KB will reduce the effectiveness of this attack. The parameter in tomcat is maxPostSize

3. Web Application Firewall - If you have a web application firewall, you can configure it to block requests that look suspicious. This is a reactive measure, but is nice to have in case you cannot use one of the above solutions.

FYI - Tomcat's documentation is here - http://tomcat.apache.org/tomcat-6.0-doc/config/http.html

Answer 5

Tomcat version affected are Apache Tomcat <= 5.5.34, <= 6.0.34, <= 7.0.22 as per the link you provided. The page lists Apache Tomcat >= 5.5.35, >= 6.0.35, >= 7.0.23 as Fixed versions.