Bug 504958 (CVE-2009-1904) - CVE-2009-1904 ruby: DoS vulnerability in BigDecimal
Summary: CVE-2009-1904 ruby: DoS vulnerability in BigDecimal
Status: CLOSED ERRATA
Alias: CVE-2009-1904
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: source=vendorsec,reported=20090608,pu...
Keywords: Security
Depends On: 505085 505086 505087 505088
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-10 08:19 UTC by Tomas Hoger
Modified: 2019-06-08 12:46 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-04-22 15:40:34 UTC


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 14:02 UTC, Andrew Clayton
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1140 normal SHIPPED_LIVE Moderate: ruby security update 2009-07-02 17:02:26 UTC

Description Tomas Hoger 2009-06-10 08:19:56 UTC
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 08:23:09 UTC
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 08:24:45 UTC
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 17:03:47 UTC
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 14:02:58 UTC
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 14:07:34 UTC
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 14:56:09 UTC
(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 17:16:43 UTC
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 20:02:41 UTC
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 15:49:51 UTC
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 18:39:12 UTC
kanarip, how do you think?

Comment 12 Mamoru TASAKA 2009-12-08 08:44:38 UTC
(Ah, kanarip seems to be on FUDCon)

Comment 13 Mamoru TASAKA 2009-12-10 15:17:46 UTC
Well, as F-10 updates request will be closed soon, I will submit
it.

Comment 14 Fedora Update System 2009-12-10 15:22:57 UTC
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 18:17:58 UTC
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.