From the upstream advisory: There is a vulnerability in the escaping code for the form helpers in Ruby on Rails. Attackers who can inject deliberately malformed unicode strings into the form helpers can defeat the escaping checks and inject arbitrary HTML. Versions Affected: 2.0.0 and *all* subsequent versions. Not affected: Applications running on ruby 1.9 Fixed Versions: 2.3.4, 2.2.3 Candidate CVE: CVE-2009-3009 Due to the way that most databases either don't accept or actively cleanse malformed unicode strings this vulnerability is most likely to be exploited by non-persistent attacks however persistent attacks may still be possible in some configurations. This affects rubygem-rails in Fedora 10, 11, rawhide, and EPEL 5. Upstream versions fixing the issue for 2.2.x and 2.3.x will be available Sept 3, 2009 after the vulnerability announcement is made.
Created attachment 359553 [details] patch to fix CVE-2009-3009 in rails 2.1.x In the event upstream does not push a new 2.1.x release, this patch will correct the issue.
Created attachment 359554 [details] patch to fix CVE-2009-3009 in rails 2.3.x
Embargo has been lifted: http://groups.google.com/group/rubyonrails-security/browse_thread/thread/48ab3f4a2c16190f
MITRE's CVE-2009-3009 record: ----------------------------- Cross-site scripting (XSS) vulnerability in Ruby on Rails 2.x before 2.2.3, and 2.3.x before 2.3.4, allows remote attackers to inject arbitrary web script or HTML by placing malformed Unicode strings into a form helper. References: ----------- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3009 http://groups.google.com/group/rubyonrails-security/msg/7f57cd7794e1d1b4?dmode=source http://weblog.rubyonrails.org/2009/9/4/xss-vulnerability-in-ruby-on-rails http://www.securityfocus.com/bid/36278 http://www.osvdb.org/57666 http://securitytracker.com/id?1022824 http://secunia.com/advisories/36600 http://www.vupen.com/english/advisories/2009/2544 http://xforce.iss.net/xforce/xfdb/53036
This issue affects the versions of ruby-activesupport package, as shipped with Fedora release of 10 and 11. Patch from: http://groups.google.com/group/rubyonrails-security/msg/7f57cd7794e1d1b4?dmode=source seems to be applicable. Please fix.
David, any progress while scheduling the updates?
On rawhide: done http://koji.fedoraproject.org/koji/taskinfo?taskID=1693160 For F-11: Opinions welcome about whether we should upgrade rubygems to 1.3.5 or not (rubygem-rails 2.3.4 requires rubygems >= 1.3.4, current rubygems on F-11 is 1.3.1), already mailed to rubygem-rails and rubygems maintainers.
rubygem-actionpack-2.1.1-3.fc10,rubygem-activesupport-2.1.1-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/rubygem-actionpack-2.1.1-3.fc10,rubygem-activesupport-2.1.1-2.fc10
rubygem-actionpack-2.1.1-3.el5,rubygem-activesupport-2.1.1-2.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/rubygem-actionpack-2.1.1-3.el5,rubygem-activesupport-2.1.1-2.el5
rubygem-actionpack-2.3.3-2.fc11,rubygem-activesupport-2.3.3-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/rubygem-actionpack-2.3.3-2.fc11,rubygem-activesupport-2.3.3-2.fc11
rawhide: comment 9 F-11: comment 12 F-10: comment 11 EL-5: comment 10
(In reply to comment #13) F-10: comment 10 EL-5: comment 11
rubygem-actionpack-2.1.1-3.el5, rubygem-activesupport-2.1.1-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
rubygem-actionpack-2.1.1-3.fc10, rubygem-activesupport-2.1.1-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
rubygem-actionpack-2.3.3-2.fc11, rubygem-activesupport-2.3.3-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
All branches fixed.
Not fixed on F-11, due to a bunch of rubygem-* packages having versioned requirements on rubygem-actionpack-2.3.2. Such packages include: rubygem-activerecord rubygem-activeresource rubygem-rails I am not really familiar with the Ruby and the Rails stuff, but I guess this security update should be installable in some way. BTW, a similar issue appears with the versioned dependencies on rubygem-actionpack.
rubygem-activerecord-2.3.3-2.fc11,rubygem-activeresource-2.3.3-2.fc11,rubygem-rails-2.3.3-3.fc11,rubygem-actionmailer-2.3.3-3.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/rubygem-activerecord-2.3.3-2.fc11,rubygem-activeresource-2.3.3-2.fc11,rubygem-rails-2.3.3-3.fc11,rubygem-actionmailer-2.3.3-3.fc11
If you push this update and everyone upgrades to Rails 2.3.3, existing applications will break because of this piece of the default config/environment.rb: # Specifies gem version of Rails to use when vendor/rails is not present RAILS_GEM_VERSION = '2.3.2' unless defined? RAILS_GEM_VERSION The Rails version shouldn't be bumped in F11. You're not even attempting to go to the current version of Rails upstream. The security patches apply just fine to 2.3.2, and that's what should have been patched here. The only reason 2.3.3 is being pushed now is that kanarip imported new sources, and never pushed them out to the distro, so when a rebuild happened for this security patch, it's causing everyone to be upgraded to 2.3.3. Please back out to 2.3.2 and apply the security patch there.
You can set RAILS_GEM_VERSION environment then, so no problem. Honestly saying, I think if a software which expects just rubygem-rails = 2.3.2 and fails suddenly with 2.3.4 it is a serious bug in the software. It is highly expected that another bugs, not specific to security issues, will be found on rails and another bug fix releases with minor release number bump will be released at the time. At that time, postponeing bug fix of rails on Fedora because some software cannot handle such minor release bump of rails while rails' API does not change is certainly a bug in that software and that software must be fixed. Also rubygem-activesupport 2.3.3 is already pushed and we cannot revert it.
Mamoru, I believe you're misunderstanding the problem. Yes, if everyone with an existing application goes and sets the RAILS_GEM_VERSION environment variable, or edits the environment.rb file, their application will once again work unless it has a serious bug. That's not the point. The point is that the restriction to 2.3.2 in environment.rb is set up *by default* when you first run 'rails' to initialize an application. This means that anyone who has set up a rails app on Fedora 11 will have their app stop working when they take this update, until they notice that their app has broken and go make the change. It is irresponsible for the maintainers of a package to push an update that pointlessly breaks most existing applications. Fedora 12 is due out very soon now, and that would be the right time to push a backwards-incompatible update. You could argue that Rails has a bug in that its default framework ties to you a hardcoded version, and I'd agree with you - it should be possible to upgrade the package version without breaking your application. The software that needs to be fixed is Rails, because it will break applications on upgrade that should be perfectly compatible with the new version. The only people who were able to successfully take the rubygem-activesupport 2.3.3 update were the ones who don't have rubygem-rails installed, which is probably not many people, or the ones running packages out of updates-testing, who expect some updates to not work. You could back out to 2.3.2 by bumping the epoch of the package, and I urge you to consider doing so. You've attempted to push a software version change as a security update, when in fact the security patch isn't included in the version you're updating to (so you had to manually apply it), and it applies cleanly to the version of the software currently in the release.
I agree that we shouldn't break existing apps with an update (and I am firmly pointing my finger at upstream rails for the insanity of hardcoding version numbers to avoid any semblancce of API stability) I am revoking the push request for now, and will see about pushing a patched 2.3.2 into F-11 on Monday.
Thank you very much. I'm presently running locally built 2.3.2 packages with the same patch that you folks applied to 2.3.3, and it seems to work fine. Let me know if you'd like any assistance testing what you come up with. Also, I see that you added a negative comment to Bodhi, though it still lists the status as "pending." Is this just a bug in the Bodhi display, or was the revocation unsuccessful?
rubygem-actionmailer-2.3.2-3.fc11,rubygem-actionpack-2.3.2-2.fc11,rubygem-activerecord-2.3.2-2.fc11,rubygem-activeresource-2.3.2-2.fc11,rubygem-activesupport-2.3.2-2.fc11,rubygem-rails-2.3.2-5.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/rubygem-actionmailer-2.3.2-3.fc11,rubygem-actionpack-2.3.2-2.fc11,rubygem-activerecord-2.3.2-2.fc11,rubygem-activeresource-2.3.2-2.fc11,rubygem-activesupport-2.3.2-2.fc11,rubygem-rails-2.3.2-5.fc11
rubygem-actionmailer-2.3.2-3.fc11, rubygem-actionpack-2.3.2-2.fc11, rubygem-activerecord-2.3.2-2.fc11, rubygem-activeresource-2.3.2-2.fc11, rubygem-activesupport-2.3.2-2.fc11, rubygem-rails-2.3.2-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
I guess this one is already fixed.