Bug 750564 (CVE-2011-4815) - CVE-2011-4815 ruby: hash table collisions CPU usage DoS (oCERT-2011-003)
Summary: CVE-2011-4815 ruby: hash table collisions CPU usage DoS (oCERT-2011-003)
Alias: CVE-2011-4815
Product: Security Response
Classification: Other
Component: vulnerability   
(Show other bugs)
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Whiteboard: impact=moderate,public=20111228,repor...
Keywords: Security
Depends On: 768828 768829 768830 768831 768833 770818 771529 771535 802932 844296
Blocks: hashdos, oCERT-2011-003 750567
TreeView+ depends on / blocked
Reported: 2011-11-01 15:21 UTC by Jan Lieskovsky
Modified: 2018-11-29 21:28 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-02-13 13:45:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch by ruby security team. (6.44 KB, patch)
2011-11-30 17:49 UTC, KOSAKI Motohiro
no flags Details | Diff
patch Dec 11 (6.21 KB, patch)
2011-12-11 18:49 UTC, KOSAKI Motohiro
no flags Details | Diff
patch provided by oCERT (official upstream patch) (6.21 KB, patch)
2011-12-12 19:31 UTC, Vincent Danen
no flags Details | Diff
RHEL-5.8 patch (5.63 KB, patch)
2011-12-21 16:29 UTC, Vít Ondruch
no flags Details | Diff
RHEL-4.9 patch (7.19 KB, patch)
2011-12-23 14:24 UTC, Vít Ondruch
no flags Details | Diff
RHEL-4.9 patch (3.95 KB, patch)
2012-01-17 13:49 UTC, Vít Ondruch
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0069 normal SHIPPED_LIVE Moderate: ruby security update 2012-01-30 23:30:49 UTC
Red Hat Product Errata RHSA-2012:0070 normal SHIPPED_LIVE Moderate: ruby security update 2012-01-30 23:28:11 UTC

Description Jan Lieskovsky 2011-11-01 15:21:30 UTC
Julian Wälde and Alexander Klink reported a flaw in the hash function used in the implementation of the Ruby arrays implemented using the hash table.

A specially-crafted set of keys could trigger hash function collisions, which degrade hash table performance by changing hash table operations complexity from an expected/average O(1) to the worst case O(n).  Reporters were able to find colliding strings efficiently using equivalent substrings or meet in the middle techniques.

As various web application frameworks for Ruby automatically pre-fill certain arrays with data from the HTTP request (such as GET or POST parameters) for Ruby web application, a remote attacker could use this flaw to make Ruby interpreter use excessive amount of CPU time by sending a POST request with large amount of parameters which hash to the same value.

This problem is similar to the issue that was previously reported for and fixed in e.g. perl:

Note: This issue did not affect Ruby 1.9, which already randomizes hash function in a similar way perl does.

Comment 2 Jan Lieskovsky 2011-11-01 15:23:49 UTC

Red Hat would like to thank oCERT for reporting this issue. oCERT acknowledges Julian Wälde and Alexander Klink as the original reporters.

Comment 11 KOSAKI Motohiro 2011-11-30 17:49:38 UTC
Created attachment 538673 [details]
Proposed patch by ruby security team.

Caution: This is still under reviewing and ruby security team may change it later. This code should be used for that an assigned engineer understand the issue.

Comment 12 KOSAKI Motohiro 2011-12-11 18:49:48 UTC
Created attachment 545391 [details]
patch Dec 11

We ruby security team agreed a way of hash implementation with Julian Wälde who is the original reporter and changed a patch slightly. I've attached it. I suspect it is final patch.

Also, we agreed ruby core team release new patch level release at the same day with the unembargo date (i.e Dec 27), it is called ruby-1.8.7p357.

Comment 15 Vít Ondruch 2011-12-12 14:49:01 UTC
(In reply to comment #12)

Hi Motohiro,

Thank you for the patch and the information abour Ruby release schedule. However, could you please elaborate what is the fix actually fixing? What is the actual cause of the slowness?

If I read the patch correctly, it seems, that you are going to significantly decrease the possibility of the DOS, because you added the random seed, therefore it is now statistically low chance that attacker would be successful, but the chances are not 0. Am I right?

Comment 16 KOSAKI Motohiro 2011-12-12 15:50:04 UTC
Hi Vit,

following is my draft paper of the security announce. I hope this help you understand.

The problem are
- If there are hash collisioned string, string performance may decrease a lot.
  So an attacker may try to make billion collisioned string intentionally.
- Current hash function is too simple and attacker can easily make reverse hash
  function. IOW, to make collision is very easy.
- More unfortunately, ruby 1.8 use the same hash seed every time. Then, an
  attacker can make collisioned string on their local machine.
- An attacker can send lots string at ones by using HTTP POST parameter into
  the target host.


If an attacker needs enough a lot of time to make hash collision strings, admin can prevent the attack by simply restarting the server.  To clarify, you have good point.  We had two ways to fix 1) fix too simple ruby hash 2) fix Rails that don't have enough DoS detection.  We chose 1) because it can fix all ruby application framework by one fix.

Ruby upstream advisory draft:

Denial of service attack was found for Ruby's Hash algorithm


This is  something related  to computational complexity.   A specially
crafted  series  of strings  that  intentionally  collides their  hash
values each other was found.   With the sequence an attacker can issue
a denial  of service  attack by, for  instance, giving the  strings as
POST parameters of HTTP requests for your Rails application.

This is  a DoS  threat.  We  have not yet  been successful  to execute
arbitrary codes by exploiting this vulnerability.

<"続きを読む" tag here>

Detailed description:

The situation is similar to the one  found for Perl in 2003.  We use a
deterministic hash  function to  hash a string,  where "deterministic"
means no  other bits  of information than  the input string  itself is
involved to generate a hash  code.  So you can precalculate a string's
hash   code  beforehand  (given   ruby's  open-sourced   nature).   By
collecting a series of strings  that have the identical hash value, an
attacker  can let  ruby process  collide  bins of  hash tables.   Hash
tables' amortized O(1) attribute depends on uniformity of distribution
of hash  values.  By  giving such crafted  input, an attacker  can let
hash tables work much slower  than expected (namely O(n2) to construct
a n-elements hash this case).

Affected versions:

- - Ruby 1.8.7-p352 and all prior versions.

All  Ruby 1.9  series are  not affected.   They are  relatively modern
implementations, already prepared to this kind of attack.


Our  solution  is  to  scramble  the  string  hash  function  by  some
PRNG-generated random bits.  By doing  so a string's hashed code is no
longer deterministic.   That is, a `String#hash`  result is consistent
only for current process lifetime and will generate a different number
for the next boot.  To break  this situation an attacker must create a
set of strings  which are robust to this kind  of scrambling, which is
believed to be quite difficult.

Please upgrade to the latest version of ruby via <修正版へのリンク>.


* Bear in  mind that our  hash algorithm is  still _cryptographically_
 _insecure_.  To put it simple, we fixed the hash table but we didn't
 fix  `String#hash` weakness.   An attacker  coudld still  exploit it
 once he  / she got a  pair of a  string and its hash  value returned
 from  `String#hash`.    You  _must_  _not_   disclose  `String#hash`
 outputs.  If you need to  do such things, consider using secure hash
 algorithms instead.  Some  of them (such as SHA256)  are provided in
 Ruby's standard library.

* In fact,  we have traditionally been providing  two alternative hash
 algorithms, apart  from the default  one.  They are  only accessible
 via recompiling a  ruby binary with magical C  compiler flags.  Most
 of you don't  even know it.  I have never seen  their used in actual
 situations.  If you  know about them and you do use  one of them, do
 so at  your own risk please.   By choosing them we  consider you can
 read C, and you can understand  what was wrong with the default one.
 Make sure that your choice is safe.

Comment 17 Vít Ondruch 2011-12-12 16:58:54 UTC
Hi Motohiro,

Thank you for the announcement draft. It is very well written and it confirms my suspicion. However I am still interested in one point:

(In reply to comment #16)
>  - If there are hash collisioned string, string performance may decrease a lot.
> So an attacker
>     may try to make billion collisioned string intentionally.

Do you have some example code or reference what is the reason for this performance decrease? I can imagine there are other ways how to feed Ruby with such data, e.g. files, web input forms, etc.

Comment 18 KOSAKI Motohiro 2011-12-12 17:46:34 UTC
I don't have. Original reporter plan to publish it at Dec 27th. But he telled us it use very long http post data and string hash collision.

Comment 19 Vincent Danen 2011-12-12 19:31:09 UTC
Created attachment 545892 [details]
patch provided by oCERT (official upstream patch)

The official upstream patch, as provided by oCERT, which will be in ruby 1.8.7-p357.

Comment 20 Jan Lieskovsky 2011-12-15 10:30:22 UTC
The CVE identifier of CVE-2011-4815 has been assigned to this issue in Ruby, CRuby and JRuby languages.

Comment 21 Huzaifa S. Sidhpurwala 2011-12-16 06:48:57 UTC
CVE split for Ruby(C) and JRuby:

CVE-2011-4815  Ruby (CRuby)
CVE-2011-4838  JRuby

Comment 23 Vít Ondruch 2011-12-21 16:29:43 UTC
Created attachment 549056 [details]
RHEL-5.8 patch

I have backported the patch for Ruby 1.8.5 for RHEL-5. Motohiro, could you please review the patch? I had to replace rb_genrand_int32 with genrand_int32 and remove the static. Not sure if I should not rather backport the rb_genrand_int32 patch [1].

However, I don't know how to test it :/ Rails 3 are not compatible with Ruby 1.8.5 and older Rails 2.3 fails probably sooner than the POST content is parsed. Any thoughts?

[1] https://github.com/ruby/ruby/commit/e926ef5233cc9f1035d3d51068abe9df8b5429da

Comment 30 Vít Ondruch 2011-12-23 14:24:14 UTC
Created attachment 549355 [details]
RHEL-4.9 patch

I have backported the patch for RHEL-4. Its bit trickier, however it seems it works.

Comment 32 Tomas Hoger 2011-12-29 10:20:13 UTC
This issue was presented on 28C3:

Details were posted to full-disclosure:

oCERT advisory:

n.runs advisory (copy of the full-disclosure post):

28C3 slides and recording:

Another good write-up of the issue:

Upstream has released an advisory for this issue:

The issue was fixed in Ruby 1.8.7-p357:

Upstream commit:

Ruby upstream fix add hash function randomization to Ruby 1.8.  Hash seed is initialized on ruby interpreter start up and hence differs in between executions.

Comment 33 Huzaifa S. Sidhpurwala 2011-12-29 10:36:52 UTC
Created ruby tracking bugs for this issue

Affects: fedora-all [bug 770818]

Comment 34 Tomas Hoger 2011-12-29 10:38:04 UTC
Additional mitigation in Ruby Rack that limits total length of keys (parameter names) parsed from the HTTP request:

Comment 35 Tomas Hoger 2012-01-02 08:03:37 UTC
(In reply to comment #34)
> Additional mitigation in Ruby Rack that limits total length of keys (parameter
> names) parsed from the HTTP request:
> https://gist.github.com/52bbc6b9cc19ce330829

Tracked also via separate bug #771149.

Comment 40 Fedora Update System 2012-01-11 06:06:47 UTC
ruby- has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 41 Fedora Update System 2012-01-11 06:14:47 UTC
ruby- has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 42 Vít Ondruch 2012-01-17 13:49:14 UTC
Created attachment 555782 [details]
RHEL-4.9 patch

The original patch was too complex and needed far more backporting. This was demonstrated by issues with fixing CVE-2011-3009. So I took simpler approach.

Comment 43 errata-xmlrpc 2012-01-30 18:33:39 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2012:0070 https://rhn.redhat.com/errata/RHSA-2012-0070.html

Comment 44 errata-xmlrpc 2012-01-30 18:33:52 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2012:0069 https://rhn.redhat.com/errata/RHSA-2012-0069.html

Note You need to log in before you can comment on or make changes to this bug.