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
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.
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.
Sign in or Join to comment or subscribe