09 Jan 2013
THE Ruby on Rails Vulnerabilities of 2013 - What they are and what should we do?
posted by Adam J. O Donnell, Ph.D.
A little under 24 hours ago two major, long-standing vulnerabilities were announced in the popular web programming framework Ruby on Rails. This blog post will talk about what is currently known about these vulnerabilities, what could happen based on previous experiences with these types of vulnerabilities, and what organizations and consumers need to know in order to stay aware and stay protected.
The vulnerabilities (CVE-2013-0155 and CVE-2013-0156) deal with how data passed in by the user is parsed and handled by the Rails application. The second vulnerability (0156) is the more severe of the two, as it allows for full remote code execution against any Ruby on Rails application that has the XML parser enabled, which is case by default. More plainly, it means that anyone can run a unix command with the same privileges as the Ruby on Rails application under the default install, even if you are not processing XML as part of the code you created.
Rails programmers and administrators can remediate both issues by upgrading to the latest version of Ruby on Rails. Additional workarounds exist if this is not an option. The first vulnerability can only be addressed by adding additional data parameter scrubbing code to the application, while the second vulnerability can be addressed by disabling the XML parser. This may not be an option for every website as they may consume XML from the user as a matter of routine operation.
New versions of Ruby on Rails that address the vulnerabilities are available here.
Those are the facts as of this time. Let's talk about what this all means.
Yes, this looks to be pretty bad
This isn’t some random cross site scripting vulnerability on a website that no one ever uses. This is a bug in one of the most popular web programming frameworks on the planet that exists in the default install, and this bug appears to allow anyone to execute commands on the web server that hosts the software as well as pull any data out of the backend database that the web server itself can access. This isn’t just SQL injection. This is bad. We should all be taking this issue pretty seriously.
Furthermore, any time a severe vulnerability like this pops up, more minds are attracted to the same code base to look for similar vulnerabilities. I wouldn’t be surprised if there are aftershocks of similar issues in the coming days.
Many organizations could be vulnerable for hours or days, some for weeks or longer
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.
“Do we have wormsign?”
As of right now we have reason to believe that this vulnerability can be used for the creation of a worm. Historically, vulnerabilities that affect common web servers or web programming languages and allow remote code execution have shown that they can be turned into worms. The pervasiveness of the vulnerable software as well as the ease of exploitation recalls the environmental factors that allowed for the rise of the Code Red worm of 2001.
Thankfully we have significant academic analysis of data collected on the propagation of the worm as well as epidemiological models that could help us predict what a worm outbreak could look like . The data shows that in the 2001 outbreak the number of system infected reached a saturation point in under 12 hours. While there are many factors that would influence the rate of propagation of a contemporary worm, such as the rate at which vulnerable sites are repaired, how many Ruby on Rails websites exist in the world, and how easy it is to discover vulnerable sites, I would keep in mind that a similar worm outbreak could reach saturation in a matter of hours.
As of this very second we have no evidence that a worm is actively propagating, but frankly that could change at any time.
It is my opinion that we have to consider that a worm is not the most serious threat we could face. The worst case situation is that attackers use the vulnerability to silently compromise massive numbers of vulnerable websites, grab everything from the database, and install persistent backdoors in the infrastructure of every organization running the vulnerable code. They could also silently post a client-side exploit that targets people who come to that site, commonly known as a Watering Hole attack. A worm would likely force everyone to fix their infrastructure immediately, while silent exploitation may not be as motivating. Which leads to...
So you scared me, now what do I do?
If you are running Rails code, stop what you are doing and upgrade your Rails environment right now. If you are managing people who are writing Rails code, get them to upgrade their environment immediately. If you are a web hoster that has a significant number of people running Rails code, contact your customers and get them to upgrade. Order lunch in. Don’t go home. Stop reading this and fix the problem. You get the idea.
Stay tuned for more information on this as it develops.
 Cliff Changchun Zou , Weibo Gong , Don Towsley, Code red worm propagation modeling and analysis, Proceedings of the 9th ACM conference on Computer and communications security, November 18-22, 2002, Washington, DC, USA
comments powered by Disqus