A security issue has been discovered in Ruby on Rails, a popular web application framework. It is a serious one:
There are multiple weaknesses in the parameter parsing code for Ruby on Rails which allows attackers to bypass authentication systems, inject arbitrary SQL, inject and execute arbitrary code, or perform a DoS attack on a Rails application. This vulnerability has been assigned the CVE identifier CVE-2013-0156.
Versions Affected: ALL versions
Not affected: NONE
Fixed Versions: 3.2.11, 3.1.10, 3.0.19, 2.3.15
and also worth noting:
An attacker can execute any ruby code he wants including system("unix command"). This effects any rails version for the last 6 years. I’ve written POCs for Rails 3.x and Rails 2.x on Ruby 1.9.3, Ruby 1.9.2 and Ruby 1.8.7 and there is no reason to believe this wouldn’t work on any Ruby/Rails combination since when the bug has been introduced. The exploit does not depend on code the user has written and will work with a new rails application without any controllers.
You can grab patched versions here.
How quickly can an organisation patch its applications? As Sourcefire security architect Adam J. O Donnell observes, this is where strong DevOps pays dividends:
Modern web development practices have made major leaps when it comes to shortening the time from concept to deployment. After a programmer makes a change, they run a bunch of automated tests, push the change to a code repository, where it is picked up by another framework that assures the changes play nice with every other part of the system, and is finally pushed out to the customer-facing servers. The entire discipline of building out all of this infrastructure to support the automated testing and deployment of software is known as DevOps.
In a perfect world, everyone practices devops, and everyone’s devops workflow is working at all times. We don’t live in a perfect world.
For many organizations changing a library or a programming framework is no small task from a testing and deployment perspective. It needs to go through several steps between development and testing and finally deployment. During this window the only thing that will stop an attacker is either some form of network-layer technology that understands how the vulnerability is exploited or, well, luck.
This site runs WordPress, and if I look at the logs I see constant attack attempts. In fact, I see the same attacks on sites which do not run WordPress. The bots that do this are not very smart; they try some exploit against every site they can crawl and do not care how many 404s (error showing page not found) they get. One in a while, they hit. Sometimes it is the little-used applications, the tests and prototypes, that are more of a concern than the busy sites, since they are less likely to be patched, and might provide a gateway to other sites or data that matter more, depending on how the web server is configured.