There is a vulnerability in the SafeBuffer#[] in Ruby On Rails where unescaped safe buffers can be marked as safe. Versions Affected: All. Fixed Versions: 3.2.2, 3.1.4, 3.0.12 Impact ------ Due side effects of some optimizations in the String class, users that directly manipulate SafeBuffer objects via `[]` and other methods that return new instances of SafeBuffer may be inadvertently marked as HTML safe. All users running an affected release should either upgrade or use one of the work arounds immediately. This problem manifests itself in forms like this: x = 'foo'.html_safe x.html_safe? # => true x.gsub!('f', 'user input').html_safe? # => false x[0..-1].html_safe? # => true Or in a shorter form: 'foo'.html_safe.gsub!('f', 'user input')[0..-1].html_safe? # => true The fix will make the call to `html_safe?` return a falsey value. After the patch: x = 'foo'.html_safe x.html_safe? # => true x.gsub!('f', 'user input').html_safe? # => false x[0..-1].html_safe? # => nil Or in a shorter form: 'foo'.html_safe.gsub!('f', 'user input')[0..-1].html_safe? # => nil There is a vulnerability for users that generate their own options tags for use with the select helper in Ruby On Rails. Versions Affected: All. Fixed Versions: 3.2.2, 3.1.4, 3.0.12 Impact ------ When developers generate html options tags manually, user input concatenated with manually built tags may not be escaped and an attacker can inject arbitrary HTML in to the document. Only manually generated select tag options are impacted, but all users running an affected release should either upgrade or use one of the work arounds immediately.
Note that there are no patches for Rails 2.3, which is currently our only stable version. We might have to look into backporting the patches, and in the mean time work on stabling newer versions.
The announcement does not mention 2.3 , sure that is affected?
(In reply to comment #2) > The announcement does not mention 2.3 , sure that is affected? No, I'm not sure. The original announcement says: "Please note that only the 3.2.x, 3.1.x, and 3.0.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible."
(In reply to comment #2) > The announcement does not mention 2.3 , sure that is affected? I have just verified the code and 2.3.x is also vulnerable. Upstream won't release patches, so we either need to backport ourselves (or find someone who has done that), or stable 3.0.x and drop 2.3.x.
(In reply to comment #4) > (In reply to comment #2) > > The announcement does not mention 2.3 , sure that is affected? > > I have just verified the code and 2.3.x is also vulnerable. Upstream won't > release patches, so we either need to backport ourselves (or find someone > who has done that), or stable 3.0.x and drop 2.3.x. Thanks for doing this. FWIW, moving to a supported version would certainly make future security bugs/bumps a lot easier. Having to backport patches is often a never-ending battle which only delays the inevitable upgrade. But that is easy for me to say. ;)
CVE-2012-1099 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-1099): Cross-site scripting (XSS) vulnerability in actionpack/lib/action_view/helpers/form_options_helper.rb in the select helper in Ruby on Rails 3.0.x before 3.0.12, 3.1.x before 3.1.4, and 3.2.x before 3.2.2 allows remote attackers to inject arbitrary web script or HTML via vectors involving certain generation of OPTION elements within SELECT elements. CVE-2012-1098 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-1098): Cross-site scripting (XSS) vulnerability in Ruby on Rails 3.0.x before 3.0.12, 3.1.x before 3.1.4, and 3.2.x before 3.2.2 allows remote attackers to inject arbitrary web script or HTML via vectors involving a SafeBuffer object that is manipulated through certain methods.
Rails 3.0.12 is now in the tree.
Rails 3.1.4 is now in the tree.
Great, thank you. Shall we move forward and stabilize =dev-ruby/rails-3.0.12?
(In reply to comment #9) > Great, thank you. Shall we move forward and stabilize =dev-ruby/rails-3.0.12? Yes, but that stabilization is quite involved. I'll file separate bugs for some of the components and include a final stabilization list here.
@maintainers: so about that stable list...
(In reply to Chris Reffett from comment #11) > @maintainers: so about that stable list... Hmm, it looks like at the time I gave the wrong response to comment 9. The correct response should have been: "No, we don't have any Rails 3.0 version stable." I think this bug can just be closed now. All affected slots are either already marked stable or don't have any stable versions.
Isn't 2.3.18 still affected, though?
(In reply to Chris Reffett from comment #13) > Isn't 2.3.18 still affected, though? Yes, it looks like we never actually went looking for a patch. Rails 2.3 was already on our shortlist to be removed due to being ruby18-only. I have now masked it.
(In reply to Hans de Graaff from comment #14) > (In reply to Chris Reffett from comment #13) > > Isn't 2.3.18 still affected, though? > > Yes, it looks like we never actually went looking for a patch. Rails 2.3 was > already on our shortlist to be removed due to being ruby18-only. I have now > masked it. And yet you have not marked anything else stable, so this breaks installs that are not accepting unstable keywords.
(In reply to Jeremy Huddleston from comment #15) > And yet you have not marked anything else stable, so this breaks installs > that are not accepting unstable keywords. What specific problem is this causing for you?
Closing noglsa since ~arch only branches were updated and stable branch was removed from tree (no GLSA for the stable branch since it is XSS)
