Over the past several years, the web development community has been enthralled with Ruby on Rails. The combination of the Ruby language with the Rails framework has proven extremely powerful, and many of the web’s top sites are built using the two technologies. For example, sites like Twitter, 500px, Groupon and more were all built with Ruby on Rails as their framework. Both new and veteran developers have adopted the platform because of its ease of use, rich library of components, and outstanding tools.
Late last month, the gleam of Ruby on Rails dulled considerably as a new class of security attacks emerged targeting the framework. Like many security vulnerabilities, the attacks started out as academic exercises which were quickly spun into automated attack bots designed to knock over Rails servers en masse.
Today, anyone who runs a Ruby on Rails server who hasn’t applied an update is probably already compromised. Think that’s overstating things a bit? Patrick McKenzie sounds the alarm loudly in his blog post titled What The Rails Security Issue Means For Your Startup:
It is imperative that you understand that all Rails applications will eventually be targeted by this and similar attacks, and any vulnerable applications will be owned, regardless of absence of these risk factors.
Still think that’s overstating things? Attackers used this new vulnerability to launch a 0-day attack on the Rubygems server itself, compromising it and potentially all of the hosted gems (gems are modules written by developers to expand on the core functionality of Rails). If the official Rails gem repository can be hacked, then so can your website. (By the way, did you know that Ruby gems are not cryptographically signed, meaning it’s impossible for a user to tell if they’ve been modified by an attacker?)
So what’s going on here? Rails makes extensive use of the YAML format for structuring any kind of data used by the framework, but it turns out that YAML isn’t all that safe to use without first sanitizing the input. A malicious attacker can include code inside a YAML object that should only contain data. Rails’ YAML interpreter will then execute that code at the same time it interprets the data.
As vulnerabilities go, this one shares a kinship with dozens of other kinds of vulnerabilities. SQL injections and cross site scripting attacks both rely on the same kind of approach – code is embedded in a stream that should only contain data. Somehow, that code is executed leading to mayhem.
This problem will haunt Ruby on Rails users for years. Sadly, anyone who uses a Ruby on Rails website (which is pretty much everyone) will be affected each time sensitive data, passwords, or information is stolen and shared. Be careful, develop safely, keep your sites patched, and hope that everyone else does the same. Oh, and make sure your site is security tested for good measure.