[CVE-2013-4491] Reflective XSS Vulnerability in Ruby on Rails

4,087 views
Skip to first unread message

Aaron Patterson

unread,
Dec 3, 2013, 2:08:00 PM12/3/13
to rubyonrail...@googlegroups.com, oss-se...@lists.openwall.com, ruby-sec...@googlegroups.com
Reflective XSS Vulnerability in Ruby on Rails

There is a vulnerability in the internationalization component of Ruby on Rails. Under certain common configurations an attacker can provide specially crafted input which will execute a reflective XSS attack. This vulnerability has been assigned the CVE identifier CVE-2013-4491.

Versions Affected: 3.0.6 and all later versions.
Not affected: 3.0.5 and earlier 3.0.x versions.
Fixed Versions: 4.0.2, 3.2.16.

The root cause of this issue is a vulnerability in the i18n gem which has been assigned the identifier CVE-2013-4492. For this reason applications are also not affected if they have upgraded to the following i18n versions:
* i18n-0.6.6 for Rails 4.0.x and 3.2.x applications
* i18n-0.5.1 for Rails 3.1.x and 3.0.x applications

Impact
------
When the i18n gem is unable to provide a translation for a given string, it creates a fallback HTML string. Under certain common configurations this string can contain user input which would allow an attacker to execute a reflective XSS attack.

All users running an affected release should either upgrade or use one of the workarounds immediately.

Releases
--------
The 4.0.2 and 3.2.16 releases are available at the normal locations.

Workarounds
-----------
To work around this issue you must replace the standard i18n exception handler with a fixed one. Place the following code into a file in the config/initializers directory of your project and restart the server.

require 'i18n'

# Override exception handler to more carefully html-escape missing-key results.
class HtmlSafeI18nExceptionHandler
Missing = I18n.const_defined?(:MissingTranslation) ? I18n::MissingTranslation : I18n::MissingTranslationData

def initialize(original_exception_handler)
@original_exception_handler = original_exception_handler
end

def call(exception, locale, key, options)
if exception.is_a?(Missing) && options[:rescue_format] == :html
keys = exception.keys.map { |k| Rack::Utils.escape_html k }
key = keys.last.to_s.gsub('_', ' ').gsub(/\b('?[a-z])/) { $1.capitalize }
%(<span class="translation_missing" title="translation missing: #{keys.join('.')}">#{key}</span>)
else
@original_exception_handler.call(exception, locale, key, options)
end
end
end

I18n.exception_handler = HtmlSafeI18nExceptionHandler.new(I18n.exception_handler)

This initializer has also been attached to this message as html_safe_i18n_exception_handler.rb

Patches
-------
To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

* 4-0-i18n_xss.patch - Patch for 4.0 series
* 3-2-i18n_xss.patch - Patch for 3.2 series

Please note that only the 4.0.x and 3.2.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee the continued availability of security fixes for unsupported releases.

Credits
-------
Thanks to Peter McLarnan of Matasano Security for reporting the issue to us, and to Sven Fuchs and Christopher Dell for working with us on the fix.

--
Aaron Patterson
http://tenderlovemaking.com/
3-2-i18n_xss.patch
4-0-i18n_xss.patch

ch...@tigrish.com

unread,
Dec 5, 2013, 5:32:23 PM12/5/13
to ruby-sec...@googlegroups.com, rubyonrail...@googlegroups.com, oss-se...@lists.openwall.com, tende...@ruby-lang.org
With this update I18n introduced a `enforce_available_locales` setting that I'd like to clarify :

When I18n initialises, it creates an array of the known locales called I18n.available_locales.
Typically, this array is created by scanning for YML files (in config/locales for a Rails app).

With I8n.enforce_available_locales set to true, we check that the locale we're trying to use (eg. translate or localize) is included in the available_locales. This means we're certain it can't be malicious user submitted data even outside of the scope of a Rails app.
Reply all
Reply to author
Forward
0 new messages