Security should always be at the forefront of your mind when developing on the web, and for Ruby and Rails developers that has definitely been the case recently. Multiple exploitations over the last month have sounded the alarms for anyone that has a Ruby or Ruby on Rails app deployed.
How does this affect you?
These bugs allow “attackers to bypass authentication systems, inject arbitrary SQL, inject and execute arbitrary code, or perform a DoS attack on a Rails application.” To break that down: the attacker will have the full ability to run code on your system. With this security opening, they can now take over your server, and it doesn’t stop there.
As Patrick McKenzie noted, this may affect you even if your project doesn’t use Ruby or Rails—it could even impact you if your site is using static HTML. He says:
Look for analytics providers and other folks on that list who have instructed you to embed JS on your website. If I do this exercise, I come up with at least three results here. Do any of them use Ruby on Rails? (Are you sure? Remember, if they have at least one Rails app on their network…) Great. If they didn’t patch in a timely manner, you should assume that JavaScript you’re embedding on your website is in the hands of the enemy. It is now a cross-site scripting vulnerability against every page it is embedded on. Do you embed it on e.g. log in pages or anywhere your admins expose their own all-powerful admin cookies? Boo, now the enemy has your password / cookies / etc.
Scared? Honestly, you probably should be. This is a really big deal—in fact, it is officially a Big Goddamned Deal™.
What can you do?
The first thing that should be on your mind right now is whether or not you have any Rails apps that are externally facing. If you do, immediately upgrade the Rails with a new patch. If you cannot do this, pull the plug on the app. Everyone is a potential target here: people will be scanning IP addresses and, with tools like Metasploit, can easily find their way into your server and claim it as their own. Seriously, if you do not upgrade and you do not pull the plug, this will happen to you.
Check your Rails version:
To find the version of Rails that your project is on, go into the project directory and use the bundle list command. This will print out a list of the gems installed and that your project is using. Find the “rails” entry and make sure its version number is one of the latest.
| Minor Version | Patch Version |
|---|---|
| 3.2 | 3.2.11 |
| 3.1 | 3.1.10 |
| 3.0 | 3.0.20 |
| 2.3 | 2.3.16 |
If you have one of these versions: great! Your Rails version has the latest patch and you’re protected against this particular exploit. You can skip the following “upgrade” step. If not, read on.
Upgrade:
To upgrade to the latest version of Rails, go into your Gemfile (where your gem dependencies are listed) and make sure the newest version of Rails is there:
Rails 3.2
gem "rails", "~>3.2.11"Rails 3.1
gem "rails", "~>3.1.10"Rails 3.0
gem "rails", "~>3.0.20"Rails 2.3, if you’re using Bundler
gem "rails", "~>2.3.16"Then run bundle update rails.
Rails 2.3, if you’re not using Bundler:
gem install rails -v=2.3.16Once this is done, edit your config/environment.rb and change RAILS_VERSION, near the top. After that, run rake rails:update.
Then, run all of your unit tests (we’re going to have an an angry talk later, if you don’t have unit tests). Make sure your app is stable and working, and deploy. Throw a party; provide snacks (I like those peanutbutter-filled pretzel things). Grow an inherent distrust for the third-party software you’re including in your application that is hosted elsewhere. Contact the maintainers of said software to make sure they are patched as well.
So, I’m safe now?
The short answer is: no. If in your code, at any point, you are taking user input and trusting a third party library to load content without auditing what that code does, you’re leaving yourself open. Take extreme care when you’re developing your code and do not, under any circumstances, just evaluate user input.
A little homework
- These steps will fix the issue for now, but to get a more in-depth reading on this subject—on what else other effects this security vulnerability could have and on the Rubygems exploit, read What The Rails Security Issue Means for Your Startup by Patrick McKenzie.
- To understand how to use Bundler during deployment to keep your gems more secure, read
How to Not Rely on Rubygems.org for Deployment by Steve Klabnik - Read the bug patches for Rails to see how the bug was addressed: Multiple vulnerabilities in parameter parsing in Action Pack (CVE-2013-0156) and Vulnerability in JSON Parser in Ruby on Rails 3.0 and 2.3
- To learn more about how Metasploit exploits this bug, read their blog post: Exploiting Ruby on Rails with Metasploit
- And, most importantly, read this short paper by Ken Thompson: Reflections on Trusting Trust
What now?
Security is important. Keep your ear to the ground and pay attention to Twitter, Hacker News, and any/all sources you use to get your tech information. The way this attack works and was discovered is setting the next few months up to be chaos for Ruby/Rails and any frameworks from other languages that use similar methods for parsing incoming data. Be ready to update when new patches come through.
People work tirelessly (most of the time unpaid) to make the software that you use for free. They do this under a constant watching eye of everybody who has a Twitter account that can use moments like this to get all “Ruby sux and all its people sux and omg lol.” That is, undoubtedly, the wrong response. Security is always changing, and incredibly—and increasingly—difficult to address. I’d like to take a moment to thank the Rails core team and the Rubygems team for the work they’ve put into this.
Simply running `gem list` in your Rails project directory does necessarily print gems installed for this project or in your `.bundle`. You should use `bundle list` or look in Gemfile.lock.
Thank you for catching that! Will make that change.
Well-written, I like your simple “what can you do?” section especially. Thanks!
Thanks for the heads up. I was pleased to learn that our host had already patched it, on dedicated servers as well as VPSes.
As you may know, we ask users’ their birthdays during the process of creating an account. However, there was a period of time where our system security company was not automatically rejecting people who indicated that they were under 13. Before the FTC reached out to us, we discovered and fixed this sign-up process qualification, and took further action by suspending any under age accounts that had mistakenly been allowed to be created.
Rails (like most major open-source projects) has a security announcement mailing list. They also tend to post announcements to their blog, but that’s less reliable. If you run open-source software, it’s a good idea to subscribe to the relevant security lists.
Also, since this article was posted, another security update (and, as a bonus, one for the JSON gem) has been released. You should now be running Rails 3.2.12, 3.1.11, 3.0.20, or 2.3.17 (as well as version 1.7.7 of the ‘json’ gem).