Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 02 Mar 2012 12:34:56 +0100
From: Jan Lieskovsky <jlieskov@...hat.com>
To: "Steven M. Christey" <coley@...us.mitre.org>
CC: oss-security@...ts.openwall.com, Mo Morsi <mmorsi@...hat.com>,
        Vít Ondruch <vondruch@...hat.com>
Subject: CVE Request -- Ruby on Rails (v3.0.12) / rubygem-actionpack: Two
 XSS flaws

Hello Kurt, Steve, vendors,

   as noted in:
   [1] http://weblog.rubyonrails.org/2012/3/1/ann-rails-3-0-12-has-been-released

Issue #A:
----------
A cross-site scripting (XSS) flaw was found in the way the String class, used
in Ruby on Rails, performed HTML escaping of SafeBuffer objects, when such
objects were manipulated directly via '[]' method or other methods, also
returning new instances of SafeBuffer object. By using these methods, such
newly returned SafeBuffer instances would be inadvertently marked as HTML safe.
If a Ruby on Rails application used SafeBuffer objects this way, a remote
attacker could provide a specially-crafted input, which once processed by such
SafeBuffer instance would pass the HTML escaping test without further
filtering, possibly leading to arbitrary HTML or webscript execution.

References:
[2A] http://groups.google.com/group/rubyonrails-security/browse_thread/thread/edd28f1e3d04e913
[3A] https://bugs.gentoo.org/show_bug.cgi?id=406547
[4A] https://bugzilla.redhat.com/show_bug.cgi?id=799275

Proposed upstream patches:
[5A] 
http://groups.google.com/group/rubyonrails-security/attach/1c2e01a5e42722c9/3-0-safe-buffer-slice.patch?part=3
     (against v3.0 branch)

[6A] 
http://groups.google.com/group/rubyonrails-security/attach/1c2e01a5e42722c9/3-1-safe-buffer-slice.patch?part=4
     (against v3.1 branch)

[7A] 
http://groups.google.com/group/rubyonrails-security/attach/1c2e01a5e42722c9/3-2-safe-buffer-slice.patch?part=5

     (against v3.2 branch)

Issue #B:
----------
A cross-site scripting (XSS) flaw was found in the way 'select' helper method
of the Ruby on Rails performed HTML escaping of 'select' HTML tag options, when
the tags were created manually. In this case, the select tag values might end
up unescaped. A remote-attacker could provide a specially-crafted input to Ruby
on Rails application, using select tags this way, which potentially resulted
into arbitrary HTML or webscript execution.

References:
[2B] http://groups.google.com/group/rubyonrails-security/browse_thread/thread/9da0c515a6c4664
[3B] https://bugs.gentoo.org/show_bug.cgi?id=406547
[4B] https://bugzilla.redhat.com/show_bug.cgi?id=799276

Proposed upstream patches:
[5B] 
http://groups.google.com/group/rubyonrails-security/attach/6fca4f5c47705488/3-0-select_options.patch?part=3
     (against v3.0 branch)

[6B] 
http://groups.google.com/group/rubyonrails-security/attach/6fca4f5c47705488/3-1-select_options.patch?part=4
     (against v3.1 branch)

[7B] 
http://groups.google.com/group/rubyonrails-security/attach/6fca4f5c47705488/3-2-select_options.patch?part=5
     (against v3.2 branch)

Could you allocate CVE ids for these?

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.