|
Message-ID: <4F50B060.1090209@redhat.com> 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.