Home arrow Ruby-on-Rails arrow Ruby-on-Rails Faces Second Security Flaw in a Week
RUBY-ON-RAILS

Ruby-on-Rails Faces Second Security Flaw in a Week


For the second time in a week, Ruby-on-Rails maintainers have been forced to push out what they describe as “extremely critical security fixes” to close a security hole in the popular framework. Left unpatched, the hole could allow malicious hackers to execute code in Rails applications without having to go through authentication.

Author Info:
By: Terri Wells
Rating: 5 stars5 stars5 stars5 stars5 stars / 2
January 09, 2013

print this article
SEARCH DEVARTICLES

For the second time in a week, Ruby-on-Rails maintainers have been forced to push out what they describe as “extremely critical security fixes” to close a security hole in the popular framework. Left unpatched, the hole could allow malicious hackers to execute code in Rails applications without having to go through authentication.

You can pick up the security patches for the most recent issue here. The most recently reported vulnerability first came to light on a Google group focused on Ruby-on-Rails. Like all really nasty security bugs, this one offers the hacker a number of options for attack. Claudio Guarnieri, a researcher at security company Rapid7, observed that “From a technical standpoint it's a very interesting and challenging vulnerability that can be exploited in several different ways with very dangerous outcomes, from SQL injection to code execution.”

It's important to note that this latest security issue affects all versions of Rails created within the last six years. Four updated versions contain the fix: 3.2.11, 3.1.10, 2.0.19, and 2.3.15. It's actually two flaws in one. One of the issues concerned the parameter parsing code for Ruby-on-Rails. InfoWorld explained that it “would allow attackers to bypass authentication systems” and “perform SQL injection attacks or a denial-of-service attack against applications using Rails.” This issue was numbered CVE-2013-0156.

The other security flaw lies with the Active Record. Numbered CVE-2013-0155, it “would allow an attacker to send unexpected database queries with the command 'IS NULL' due to the way Active Record interprets parameters in combination with the way that JSON parameters are parsed,” InfoWorld continued.

Earlier this month, on January 2, the maintainers of Ruby-on-Rails released versions 3.2.10, 3.1.9, and 3.0.18 to deal with another SQL injection security issue. This one was numbered CVE-2012-5664. The bad news is, if you've patched your Rails implementation for this particular security issue, that's not good enough; your system is still vulnerable to the ones that just came up today. You're going to have to patch it again.

At least you can take a little cold comfort in the thought that you're not alone. Many developers use Ruby-on-Rails. Websites featuring it that will need to upgrade include Hulu, Funny or Die, Scribd, popular e-commerce application Spree, Basecamp, Github, Pitchfork, and possibly Twitter (at least early versions of Twitter ran on RoR). In fact, as of early this month, more than 240,000 websites were using the popular open source development platform, with nearly 50,000 of them being among the most visited sites on the Internet.

It's not the most wonderful work to come back to after a holiday break, but it's good to know that the Rails maintainers are taking this seriously. They even apologized in the blog post that contained the earlier fixes. “We're sorry to drop a release like this so close to the holidays but regrettably the exploit has already been publicly disclosed and we don't feel we can delay the release,” they wrote. I'm sure they also regret this later flaw. Watch carefully as you apply the latest fixes, however, as one commenter reported that the update is introducing a bug for all JSON-based API applications that will cause them to suddenly stop accepted valid requests or to handle them incorrectly. It's not exactly the most auspicious start to the new year for Ruby-on-Rails, but at least they got the releases out before reports of actual attacks came to light.


DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

All Ruby-on-Rails Tutorials
More By Terri Wells


blog comments powered by Disqus
RUBY-ON-RAILS ARTICLES

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2014 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials