Problem solve Get help with specific problems with your technologies, process and projects.

Remediation planning for Ruby on Rails security vulnerabilities

The recent Ruby on Rails security vulnerabilities can be patched. Expert Michael Cobb discusses the fallout and offers help with remediation planning.

Ruby on Rails (RoR), a combination of the Ruby language with the Rails framework, is a popular, open source Web application development framework, due to both its rich library of components and its ease of use.

Ironically, Metasploit, a tool for developing and executing exploit code, is written in Ruby.

Still, 2013 hasn’t been a great year so far for those using RoR, as it's been hit by several security vulnerabilities. January 2 saw updated versions released to address a SQL injection vulnerability; a week later, two high-severity security bugs permitting remote code execution were found. The bugs are present in all versions released since 2007, so the Riding Rails blog advised that everyone should update immediately to the new releases, which contain fixes.

Fortunately, all of the Ruby on Rails security vulnerabilities discovered so far this year can be fixed by updating to the latest version of the platform but, until the patches are applied, every RoR application running on the Internet is at risk. To provide an idea of the potential scope of this problem, it is estimated that more than 200,000 sites use RoR, including well-known sites like Twitter, Github, Scribd and Groupon. Ironically, Metasploit, a tool for developing and executing exploit code, is written in Ruby, and the Metasploit Community, Express and Pro user interfaces use Ruby on Rails.

In assessing the severity of the known vulnerabilities, CVE Identifier CVE-2013-0156 is the most serious, as it allows remote code execution. All it requires is that the Ruby on Rails XML parser is turned on, which it is by default. RoR uses a serialization format called YAML (human-friendly data serialization) to structure and map data, such as settings in a configuration file. YAML is readable by both machines and humans, but like a lot of languages and technologies, YAML's expected output can be manipulated if the input is not sanitized first.

From the editors: More on Web application threats

Use a secure virtual machine to defend against watering hole attacks.

Emphasize security in the software development lifecycle to negate business logic attack risk.

From an attacker's perspective, including code inside a YAML object that should only contain data can trick the Rails' XML parser into executing code when it interprets data. No other conditions are needed for an attacker to be able to execute the code of his or her choice, enabling the adversary to run system commands on the server and take control of its applications and data. In a similar fashion to other vulnerabilities, such as SQL injection and cross-site scripting, this flaw relies on embedding code in input that isn't validated before being passed to a process that is only expecting a certain type of data. Although it is quite a complex exploit, hackers around the world will be actively hunting for other code paths in Rails to get to YAML.load() and exploit this flaw.

Any network running an unpatched version of Ruby on Rails is at serious risk; hackers will try to find and take over those versions that aren't patched. To remediate the issue and thwart attacks, administrators should inventory all possible instances to ensure they get patched, including those on cloud-based staging servers and other publicly accessible locations. While critical services are being patched to prevent them being found and infected by automated scanners, non-critical RoR apps can be protected by disconnecting them from the Internet. Attackers will not care that an application may not be processing valuable data; a compromised server can be useful in many ways, such as hosting malware used in other attacks. Systems should be thoroughly audited if there is the slightest suspicion that they may have been attacked prior to the patch being applied.

What is clear from this episode is that network administrators have to maintain an up-to-date list of all applications running on their servers and the technology used. For each technology, someone should be the designated expert who follows the security news for that technology; in this case, someone should be assigned to subscribe to the Ruby on Rails security update feed.

Note from the author

A separate, but related compromise on, a community resource used by most Ruby on Rails developers, is already causing headaches for many firms. A malicious gem, a library of Ruby and optionally C code, was uploaded to the repository at which used the YAML parsing vulnerability to compromise the site. Although it appears that no other gems were maliciously modified, users who are concerned can verify downloaded gems using the tools at Developers need to revisit their applications to ensure all input is sanitized, only allowing basic types or a whitelist of classes when handling input from an untrusted source.

This issue may also highlight the need for some enterprises to reduce the number of different technologies they deploy. Every enterprise application, device, development framework and the like demands resources to remain secure. This can be costly for organizations with a number of redundant systems. With that said, for mission-critical systems, in the same way that fire drills are practiced on a routine basis, an emergency response plan should be put in place to deal with critical patch releases and its effectiveness tested. Unlike a lawsuit, security vulnerabilities give you no time to prepare.

Only time will tell if this spate of problems deters future development using Ruby on Rails. The J2EE framework has had similar vulnerabilities in the past, but remains popular. A lot will depend on how many applications are successfully compromised as a direct result of these Ruby on Rails vulnerabilities and the amount of pain inflicted on organizations that develop or use the applications.

Any third-party services used in Web applications (think JavaScript snippets embedded in code for serving ads) should be checked. If the service uses RoR, it may be compromised and any content rendered on a site could be poisoned.

About the author
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is founder and managing director of Cobweb Applications Ltd., a consultancy that helps companies secure their networks and websites, and also helps them achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Michael is also a Microsoft Certified Database Administrator and a Microsoft Certified Professional.

This was last published in April 2013

Dig Deeper on Web application and API security best practices

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.