Special JRuby Release: 1.6.5.1

For the Impatient

• JRuby 1.6.5.1 is a single patch release of JRuby 1.6.5 to fix CERT advisory: CERT-2011-003. ALL USERS: PLEASE UPGRADE
• We talk about plans for the upcoming 1.6.6 release

CERT Details

###Hashing 101 (For proper CSci vocabulary and a lot of fun details about hashing also read this wikipedia article)

Hash tables apply a math function (hashing function) to the key of a key-value pair. The result of the hashing function is a location to a hash bucket which stores the key/value pair internally:

a[:heh] = 1
hashing_function(:heh) -> store :heh/1 in hash bucket #3
a[:foo] = 2
hashing_function(:foo) -> store :foo/2 in hash bucket #13
a[:bar] = 3
hashing_function(:bar) -> store :bar/3 in hash bucket #1

Hashes have many buckets and in theory all key/value pairs added to a hash will get spread out evenly across the hashes buckets. In practice, some number of keys will end up hashing into the same hash bucket (known as a hashing collision). As you get more key/value pairs stored to the same hash bucket the time to access those particular key/value pairs will slow down. This is because you need to walk some portion of the entries in the bucket to find the specific one you are looking for (hash structures will often make entries in an individual bucket a simple list structure).

a[:gar] = 4
hashing_function(:gar) -> store gar/4 in hash bucket #3 (same bucket as :heh)

In this example, accessing a[:gar] and a[:heh] may take longer than the other keys because they are sharing a hash bucket. ###The Attack The general application of the attack is for “the bad guys” to figure out a large set of values which will hash to the same hash bucket. Once they create this list they will send all those values to a server. The server will store them in a hash (think parameter list in Rack, for example). The act of storing or accessing any of those values takes longer and longer as the number of entries in a single hash bucket grows. The result will be a Denial Of Service (DOS) attack if enough values get stored.

hashing_function(:hostname) -> hash bucket #3
hashing_function(:aZ1) -> hash bucket #3
hashing_function(:cvg) -> hash bucket #3
hashing_function(:azr) -> hash bucket #3
... # many elided
hashing_function(:1fr) -> hash bucket #3
hashing_function(:yu3) -> hash bucket #3
hashing_function(:hyX) -> hash bucket #3

host = params[:hostname] # Uh oh! need to find this amongst many bucket buddies

###The Fix Adding a little bit of randomization to the hashing algorithm ends up making it much, much more difficult to figure out how to generate this type of attack. JRuby 1.6.5.1 (and all later JRuby releases) all have this additional randomization built into the hashing algorithm. The result should be decent hash bucket distribution that is difficult for attackers to predict. ###More information This vulnerability is not exclusively an issue of JRuby. Other Ruby implementations also have a similar issue (also patched today). In fact, Java and PHP also appear to be susceptible to this style of attack. For more information, please see the CERT announcement.

Also, consider that language implementations are really only susceptible to this attack via frameworks which allow an external hacker to store arbitrary and/or unbounded key/values into a hash. Ruby Rack had this vulnerability, but they have fixed things so that the amount of parameters stored is bounded by a size to remove the possibility of a DOS attack. Rack users should upgrade to the latest version. ###JRuby’s First Security Fix-Only Release We debated rolling what we have in our 1.6 branch along with the hashing vulnerability fix (mentioned above) and pushing out 1.6.6. This was unappealing for a couple of reasons:

1. For stable environments deployed using 1.6.5 we would be asking them to evaluate this security fix and any other fix we placed on JRuby 1.6 branch in the last two months. This seems like it would force more conservative users to perform their own build to manually patch just the security fix.
2. Of bugs we have fixed so far we felt we were about 10 short of what we wanted to have in JRuby 1.6.6

After consideration, we felt it best to give a security fix release now (A single security patch release JRuby 1.6.5.1 <— update to this now please) to satisfy the cautious and to wait until we felt good about the quality of 1.6.6. As they say, Open Source projects are ready when they are ready…

Hey! When will you be ready? What is missing?

It has been about two months since our last release and we suspect we can wrap things up in the next couple of weeks. We plan on releasing JRuby 1.6.6 in mid-January.

As we have been saying all through the 1.6 series, we are primarily fixing 1.9 compatibility bugs. Generally speaking, our 1.9 issue fixing has been dominated by encoding errors in Regexps, IO, and String. Here is a list of what we have done so far. It is also worth mentioned we fixed the regression which regressed Fiber (JRUBY-6170) in JRuby 1.6.5. Also the dreaded missing ‘read_nonblock’ has been fixed (JRUBY-5529).

Here is the list of issues we are plan on settling for 1.6.6. A few noteworthy mentions in this list is JRUBY-5657 (new 1.9 splat behavior), JRUBY- (new 1.9 to_ary behavior), and JRUBY-6067 (Windows YAML issue).

If there is some issue we don’t have targetted but you think is drop-dead important then please let us know…We are willing to expedite other issues if presented with a reasonable case for why it should be fixed. Please join the discussion.