Bug 504958 - (CVE-2009-1904) CVE-2009-1904 ruby: DoS vulnerability in BigDecimal
CVE-2009-1904 ruby: DoS vulnerability in BigDecimal
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
source=vendorsec,reported=20090608,pu...
: Security
Depends On: 505085 505086 505087 505088
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-10 04:19 EDT by Tomas Hoger
Modified: 2013-04-22 11:40 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-22 11:40:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix's a problem with dropping leading zeros after the decimal point in bigdecimal (1.13 KB, patch)
2009-07-08 10:02 EDT, Andrew Clayton
no flags Details | Diff

  None (edit)
Description Tomas Hoger 2009-06-10 04:19:56 EDT
New Ruby releases 1.8.6-p369 and 1.8.7-p173 were released by upstream fixing an issue with unbounded alloca use in the BigDecimal implementation, that can cause ruby interpreter to exhaust all stack memory and crash.

http://www.ruby-lang.org/en/news/2009/06/09/dos-vulnerability-in-bigdecimal/

Quoting upstream advisory:

  A denial of service (DoS) vulnerability was found on the BigDecimal
  standard library of Ruby. Conversion from BigDecimal objects into
  Float numbers had a problem which enables attackers to effectively
  cause segmentation faults.

  ActiveRecord relies on this method, so most Rails applications are
  affected by this. Though this is not a Rails-specific issue.

  Impact
  An attacker can cause a denial of service by causing BigDecimal to
  parse an insanely large number, such as:

  BigDecimal("9E69999999").to_s("F")

Ruby 1.9.x was fixed previously as is not affected.

Upstream bug reports:

http://redmine.ruby-lang.org/issues/show/794
http://redmine.ruby-lang.org/issues/show/1589

Upstream commits:

http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?view=rev&revision=23645
http://redmine.ruby-lang.org/repositories/revision/ruby-19?rev=20359

Test cases:

http://github.com/rubyspec/rubyspec/commit/95c0abbe07bf350f83d2454eb080b0bd315d59d4
http://github.com/rubyspec/rubyspec/commit/0fb6052d48eeb72c6f2d2239bba999038cad3d69
Comment 1 Tomas Hoger 2009-06-10 04:23:09 EDT
Affects ruby packages shipped in Red Hat Enterprise Linux 4 and 5, and all current Fedora versions (F9 - F12).  ruby packages in Red Hat Enterprise Linux 3 are not affected, as they do not have BigDecimal implemented.
Comment 2 Tomas Hoger 2009-06-10 04:24:45 EDT
As noted in the upstream advisory, this can be used to test:
  ruby -r bigdecimal -e 'BigDecimal("9E69999999").to_s("F")'
Comment 4 errata-xmlrpc 2009-07-02 13:03:47 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2009:1140 https://rhn.redhat.com/errata/RHSA-2009-1140.html
Comment 5 Andrew Clayton 2009-07-08 10:02:58 EDT
Created attachment 350939 [details]
Fix's a problem with dropping leading zeros after the decimal point in bigdecimal

Patch to apply on top of ruby-1.8.5-bigdecimal-CVE-2009-1904.patch
Comment 6 Andrew Clayton 2009-07-08 10:07:34 EDT
OK, that didn't quite go to plan.

(Reason for the attached patch)

We discovered a problem with this update (to RHEL 5 at least)

irb(main):002:0> require 'bigdecimal'; Float(BigDecimal("49.06"))
=> 49.6

Notice how the leading 0 from .06 has been dropped.

We tracked this down to the ruby-1.8.5-bigdecimal-CVE-2009-1904.patch patch.

Specifically the last two hunks making changes to 

VpToString(Real *a,char *psz,int fFmt,int fPlus)

If we revert those changes (see the attached patch) then we get back the expected behaviour.

irb(main):011:0> require 'bigdecimal'; Float(BigDecimal("49.06"))
=> 49.06

It also still survives the DOS attack.


Cheers,
Andrew
Comment 7 Tomas Hoger 2009-07-08 10:56:09 EDT
(In reply to comment #6)
> We discovered a problem with this update (to RHEL 5 at least)

Confirmed on RHEL-4 too, does not seem to affect upstream 1.8.6.369.

Created separate tracking bugs for the regression:
- RHEL-5 - bug #510277
- RHEL-4 - bug #510278
Comment 8 Vincent Danen 2009-12-03 12:16:43 EST
This issue still affects Fedora 10.  Was it the intention not to fix it?  Currently it is at 1.8.6.368 (in testing).  Fedora 11 and 12 have new enough versions to correct this.
Comment 9 Mamoru TASAKA 2009-12-06 15:02:41 EST
Fixed in ruby-1.8.6.368-2.fc10
http://koji.fedoraproject.org/koji/buildinfo?buildID=144915

For F-10 currently there is long-term testing upgrade
https://admin.fedoraproject.org/updates/F10/FEDORA-2009-5752
(submitted by kanarip).
Should I submit push request regardless of this previous updates
request?
Comment 10 Vincent Danen 2009-12-07 10:49:51 EST
I'm not sure how Fedora works for that kind of thing, but if you can somehow replace that update request with yours, that has this fixed, that would probably be ideal.  Thanks!
Comment 11 Mamoru TASAKA 2009-12-07 13:39:12 EST
kanarip, how do you think?
Comment 12 Mamoru TASAKA 2009-12-08 03:44:38 EST
(Ah, kanarip seems to be on FUDCon)
Comment 13 Mamoru TASAKA 2009-12-10 10:17:46 EST
Well, as F-10 updates request will be closed soon, I will submit
it.
Comment 14 Fedora Update System 2009-12-10 10:22:57 EST
ruby-1.8.6.368-2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/ruby-1.8.6.368-2.fc10
Comment 15 Fedora Update System 2009-12-11 13:17:58 EST
ruby-1.8.6.368-2.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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