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.
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.
An attacker can cause a denial of service by causing BigDecimal to
parse an insanely large number, such as:
Ruby 1.9.x was fixed previously as is not affected.
Upstream bug reports:
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.
As noted in the upstream advisory, this can be used to test:
ruby -r bigdecimal -e 'BigDecimal("9E69999999").to_s("F")'
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
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
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"))
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"))
It also still survives the DOS attack.
(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 126.96.36.1999.
Created separate tracking bugs for the regression:
- RHEL-5 - bug #510277
- RHEL-4 - bug #510278
This issue still affects Fedora 10. Was it the intention not to fix it? Currently it is at 188.8.131.528 (in testing). Fedora 11 and 12 have new enough versions to correct this.
Fixed in ruby-184.108.40.2068-2.fc10
For F-10 currently there is long-term testing upgrade
(submitted by kanarip).
Should I submit push request regardless of this previous updates
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!
kanarip, how do you think?
(Ah, kanarip seems to be on FUDCon)
Well, as F-10 updates request will be closed soon, I will submit
ruby-220.127.116.118-2.fc10 has been submitted as an update for Fedora 10.
ruby-18.104.22.1688-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.