MacKuba

The beginning of 2013 was a really bad time for the Ruby community. In the first few weeks of the year a few separate security issues were found that made everyone run to their SSH consoles to update their Rails apps. Rails itself had to be updated 4 times so far because of this, and even the rubygems.org gem repository has been hacked.

And we aren’t talking about a minor “someone with enough luck and determination can use this for some malicious purpose one day” kind of issue; some of these were the nastiest security holes we’ve seen in years. Check out this article by Patrick McKenzie about what can happen (or rather: will happen) because of these vulnerabilities.

The worst part: it’s probably not the end. The general nature of these bugs – see another article by Aaron Paterson analyzing all the ways in which you can do harm to a Ruby app – means that it’s quite likely that there’s more where that came from.

Now, I don’t know about you, but for me it’s starting to get hard to keep track of all these issues. I know Rails should be updated, but which version was that, 3.2.10 or 3.2.11? Is 2.3.17 OK or was there something newer? And what else was there, json, rack, or was it rake?

It might not be a problem if you only have one app – just do bundle update and you’re all set. But if you have a dozen, scattered over several staging and production servers and your local machine, it starts to get tricky.

I wrote a small shell script that grepped all apps deployed on our staging server and printed the versions of Rails in their gemfiles, but that wasn’t very convenient since I still had to remember which versions were fine and which weren’t. So I figured it would be nice to have something smarter that would actually remember all the gem versions for you. I couldn’t find such tool, so as you can guess, I wrote one: https://github.com/mackuba/holepicker.

How it works

The main idea is that there’s a command line tool written in Ruby, which has a JSON file that lists all the recent security-related updates to popular gems: date of the release, URL of the announcement, and a list of affected gems and updated versions. The tool scans all directories that you point it to, looking for Gemfile.lock files, and checks if they contain vulnerable gem versions.

And here’s an interesting part: the file is stored in the GitHub repository and it’s downloaded from GitHub every time you run it. The reason I’ve done it this way is to make it easier to run the checks against the very latest version of the vulnerability list. It’s kind of important to be sure that you haven’t missed any last minute updates, and it would be annoying to have to check for new gem versions every time you want to run the tool (not to mention you could just forget about updating it and happily run the scan with a year-old bug list).

Thanks to this, you could even set up a cron job to run the scan periodically – the script will return a non-zero status code if it finds any outdated gems, so you will know something is wrong, and you can configure your server to send you emergency emails if that happens.

If for some reason you don’t want to download the JSON file every time (your network is down or firewalled / GitHub is attacked by unicorns / you’re paranoid and you don’t trust me), don’t worry, the JSON file is also bundled inside the gem and there’s an option to skip redownloading it – though in this case you have no guarantee that it’s the latest version.

Results

This is more or less what you will get if you run HolePicker in a directory with some old Rails projects:

What’s next

Since I started working on HolePicker, some other projects have appeared that try to address the same problem. I know about bundler-audit, a Bundler extension, and gemcanary, a service that hasn’t been officially launched yet; there might be others too. If you like the basic idea but you don’t like my approach, check these out.

I’ve also discovered this database after I’d already finished writing the gem and this post. I’ll see if I can integrate HolePicker with it in the next version – it would definitely be better to keep a shared list in one place instead of wasting time and effort maintaining several independent lists.

BTW, if you’d like to make sure that you hear about new vulnerabilities quickly, there are a few good ways to do that. The Rails security mailing list should be a pretty reliable source. You should also follow @rails on Twitter if you haven’t done that yet. If you follow some other Rubyists, they’ll probably be retweeting like crazy next time something bad happens, so you shouldn’t miss that.

Personally, I’m going to rely on my trusted servant @rails_bot that I wrote last month to provide me with daily Ruby news – it seems to be surprisingly good at it (see the whole story here).

Let’s hope though that no one will find any security issues in any gem in the coming months, and this tool will just turn out to be useless… :)

---

Project page on GitHub: http://github.com/mackuba/holepicker

If you have any ideas, feedback, problems, anything – please let me know!