Michael Koziarski informed us about this issue via linux-distros:
There is a vulnerability in the JSON code for Ruby on Rails which
allows attackers to bypass authentication systems, inject arbitrary SQL,
inject and execute arbitrary code, or perform a DoS attack on a Rails
application. This vulnerability has been assigned the CVE identifier
Versions Affected: 2.3.x, 3.0.x
Not Affected: 3.1.x, 3.2.x
Fixed Versions: 3.0.20, 2.3.16
The JSON Parsing code in Rails 2.3 and 3.0 support multiple parsing
backends. One of the backends involves transforming the JSON into YAML,
and passing that through the YAML parser. Using a specially crafted
payload attackers can trick the backend into decoding a subset of YAML.
Note: This is a seperate vulnerability to CVE-2013-0156, if you are
running a 2.3 or 3.0 application you must still take action to protect
The 3.0.20 and 2.3.16 releases are available at the normal locations.
To work around this vulnerability you need to switch backends to the
JsonGem backend. Place this code in an application initializer:
ActiveSupport::JSON.backend = "JSONGem"
If you are running Ruby 1.8 you will need to ensure that the json or
json_pure gems are installed and in your application's Gemfile. Ruby
1.9 includes this code already.
Hans, do we wait for official packages to appear or do we patch and try to squeeze arches in in the remaining 4 days? The patch seems to be restricted to activesupport.
dev-ruby/rails:2.3 and dependencies are now in the tree, so these can be marked stable.
Rails 3.0 is now also in the tree.
Opening this up as it is now public.
Arches, please test and mark stable:
Target KEYWORDS: "amd64 ppc ppc64 x86"
lib/active_support/json/backends/yaml.rb in Ruby on Rails 2.3.x before
2.3.16 and 3.0.x before 3.0.20 does not properly convert JSON data to YAML
data for processing by a YAML parser, which allows remote attackers to
execute arbitrary code, conduct SQL injection attacks, or bypass
authentication via crafted data that triggers unsafe decoding, a different
vulnerability than CVE-2013-0156.
Added on existing GLSA draft.
This issue was resolved and addressed in
GLSA 201412-28 at http://security.gentoo.org/glsa/glsa-201412-28.xml
by GLSA coordinator Sean Amoss (ackle).