New security releases for Rails: Rails 3.2.12, 3.1.11, and 2.3.17

This year has been a rocky start for Rails, with a bunch of security upgrades that have been important to perform. The end result is a more secure Rails for us all, however, so while it’s annoying, it’s worth it.

How do I upgrade?

You need to do two things:

Upgrade your Rails. Make sure to get 3.2.12, 3.1.11, or 2.3.17.
Upgrade your JSON gem. Make sure you get 1.7.7, 1.6.8, 1.5.5.

Most of this can be done by changing your Gemfile to look like this:

gem “rails”, “3.2.12”

And then running bundle update rails. This will probably update your JSON gem as well, but to be sure, check your Gemfile.lock.

Run cat Gemfile.lock | grep “rails” and cat Gemfile.lock | grep “json”, if you see lines that look like rails (= 3.1.12) and json (1.7.7), then you’re good to go.

What are the vulnerabilities?

First, there is one fix in the 3.x series: CVE-2013-0276.

If you’re using attr_protected to blacklist items for mass assignment, a poor regex could allow someone to assign those attributes anyway. If you’re using attr_accessible to whitelist items, you’re fine.

This is also a good time to plug strong_parameters. Released as a gem for Rails 3.x, it will replace attr_accessible as the default security solution for Rails 4. If you’re starting a new Rails 3.x app today, you should default to using it, as it’s a much better solution.

If you’re on Rails 2.3 or 3.0, you have CVE-2013-0277.

If you serialize attributes into the database, they can be deserialized via YAML, with the same implications as the previous YAML vulnerabilities.

Finally, the JSON gem has CVE-2013-0269.

The JSON gem can be made to symbolize user input, which can cause a denial of service attack, since symbols are not garbage collected.

For More

You might also want to see the official release announcement, which includes hashes of the gemfiles.

Discuss at Hacker News if you have questions or thoughts to share.