JRuby 1.6.5.1 Released

The JRuby community is pleased to announce the release of JRuby 1.6.5.1.

JRuby 1.6.5.1 is a special release with a single patch applied to our
JRuby 1.6.5 source to correct CERT vulnerability CERT-2011-003
(http://www.ocert.org/advisories/ocert-2011-003.html). All users are
recommended to upgrade to JRuby 1.6.5.1 to get this security fix.

A fuller JRuby 1.6.6 with bug fixes from the last two months will be
released mid-January…

Background for the CERT advisory:

(for the impatient: predictable hashing algorithm and open access to a
hash from a server can possibly allow Denial of Service (DOS) attacks)

Hashing 101

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/soon).
In fact, Java and PHP also appear to be susceptible to this style of
attack. For more information, please see the CERT announcement
(http://www.ocert.org/advisories/ocert-2011-003.html) .

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.

For whatever reason the CERT link is not quite live yet. It will be
at some point.

-Tom

On Wed, Dec 28, 2011 at 7:51 AM, Thomas E Enebo [email protected]
wrote:

JRuby 1.6.5.1 is a special release with a single patch applied to our
JRuby 1.6.5 source to correct CERT vulnerability CERT-2011-003
(http://www.ocert.org/advisories/ocert-2011-003.html). All users are
recommended to upgrade to JRuby 1.6.5.1 to get this security fix.

if i run (the older) jruby w the -1.9 option, would i still be affected?

thanks for the update
-botp

-----Messaggio originale-----
Da: Thomas E Enebo [mailto:[email protected]]
Inviato: mercoled 28 dicembre 2011 00:27
A: ruby-talk ML; [email protected]; [email protected]
Oggetto: [ANN] JRuby 1.6.5.1 Released

The JRuby community is pleased to announce the release of JRuby 1.6.5.1.

JRuby 1.6.5.1 is a special release with a single patch applied to our
JRuby
1.6.5 source to correct CERT vulnerability CERT-2011-003
(http://www.ocert.org/advisories/ocert-2011-003.html). All users are
recommended to upgrade to JRuby 1.6.5.1 to get this security fix.

A fuller JRuby 1.6.6 with bug fixes from the last two months will be
released mid-January…

Background for the CERT advisory:

(for the impatient: predictable hashing algorithm and open access to a
hash
from a server can possibly allow Denial of Service (DOS) attacks)

Hashing 101

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/soon).
In fact, Java and PHP also appear to be susceptible to this style of
attack.
For more information, please see the CERT announcement
(http://www.ocert.org/advisories/ocert-2011-003.html) .

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.


blog: http://blog.enebo.com twitter: tom_enebo
mail: [email protected]


Caselle da 1GB, trasmetti allegati fino a 3GB e in piu’ IMAP, POP3 e
SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Capodanno al parco Oltremare Riccione: Pacchetto hotel 3 stelle in
centro + ingresso al parco.

-----Messaggio originale-----
Da: botp [mailto:[email protected]]
Inviato: gioved 29 dicembre 2011 03:45
A: ruby-talk ML
Cc: [email protected]; [email protected]
Oggetto: Re: [ANN] JRuby 1.6.5.1 Released

On Wed, Dec 28, 2011 at 7:51 AM, Thomas E Enebo [email protected]
wrote:

JRuby 1.6.5.1 is a special release with a single patch applied to our
JRuby 1.6.5 source to correct CERT vulnerability CERT-2011-003
(http://www.ocert.org/advisories/ocert-2011-003.html). All users are
recommended to upgrade to JRuby 1.6.5.1 to get this security fix.

if i run (the older) jruby w the -1.9 option, would i still be affected?

thanks for the update
-botp


Caselle da 1GB, trasmetti allegati fino a 3GB e in piu’ IMAP, POP3 e
SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
ING DIRECT Conto Arancio. 4,20% per 12 mesi, zero spese, aprilo in due
minuti!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid921&d)-12

(2011/12/29 11:44), botp wrote:

On Wed, Dec 28, 2011 at 7:51 AM, Thomas E Enebo [email protected] wrote:

JRuby 1.6.5.1 is a special release with a single patch applied to our
JRuby 1.6.5 source to correct CERT vulnerability CERT-2011-003
(http://www.ocert.org/advisories/ocert-2011-003.html). All users are
recommended to upgrade to JRuby 1.6.5.1 to get this security fix.

if i run (the older) jruby w the -1.9 option, would i still be affected?

Yes, jruby <= 1.6.5 uses sdbm Hash (good old CRuby 1.8’s hash function)
both in 1.8/1.9 mode. Please upgrade to 1.6.5.1 which uses MurmurHash2
like CRuby 1.9 (both in 1.8/1.9)

If you can’t upgrade, try to apply the patch for jruby 1.6 series[1].
If you can’t apply the patch, you might be able to get help of the
latest Rack release[2]. If you’re using WEBrick for production by
accident, here’s an experimental patch[3].

[1] https://github.com/jruby/jruby/compare/9dcd3885...2f607d21
[2] https://groups.google.com/forum/#!topic/rack-devel/Gk74wz5GH_4
[3] https://github.com/nahi/webrick/compare/0daf82f1...ruby_1_8_7

Best regards,
// NaHi

On Wed, Jan 4, 2012 at 10:08 AM, Hiroshi N. [email protected]
wrote:

(2011/12/29 11:44), botp wrote:

if i run (the older) jruby w the -1.9 option, would i still be affected?

Yes, jruby <= 1.6.5 uses sdbm Hash (good old CRuby 1.8’s hash function)
both in 1.8/1.9 mode. Please upgrade to 1.6.5.1 which uses MurmurHash2
Best regards,
// NaHi

Thank you very much, NaHi.
best regards for the new year -botp

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs