Why the Latest Rails Exploit Is Indicative of a Bigger Problem

Friday, February 15, 2013

Rohit Sethi


The latest Rails security flaw is example of a common anti-pattern. Ned Batchelder wrote an awesome post explaining how a similar issue may also exist in Python’s YAML parser. Looking at these vulnerabilities, I am reminded of similar flaws in other frameworks and libraries.

The issue in each case is an abuse of extensibility. At first glance the idea is clever: allow for run-time execution of new code or binding of server-side variables without changing your compiled code, thereby greatly enhancing extensibility. For example, provide extensions to your Python YAML parser that allow you to  create arbitrary objects and execute Python code; provide extensions to XML Template parsing that allows for arbitrary command execution; or dynamically assign user-supplied parameters to server-side variables (aka mass assignment) based on the parameter name. This kind of vulnerability is by design in contrast to many other by accident vulnerabilities. We called the mass assignment anti-pattern out several years ago when doing a security analysis of the Core Java EE Patterns for OWASP.

I have a strong feeling we’ll see more vulnerabilities of this type, particularly with the rising popularity of standards like SAML that are built upon several layers of libraries implementing and extending complex specifications. These kind of issues can sometimes be hard to catch with an automated scanning technology, which means most organizations adopting the status quo of application security due diligence will undoubtedly miss detecting some instances of extensibility abuse.

Security-minded developers can protect themselves by taking the following steps:

  • Turn off unnecessary extensibility in third party libraries and frameworks
  • Do not use untrusted input in libraries that provide broad extensibility, such as Apache’s Xalan with extensions enabled
  • Be vigilant about monitoring for and patching newly discovered vulnerabilities in frameworks and third party libraries. Wherever possible, sign up for security mailing lists or groups like Ruby on Rails Security
Possibly Related Articles:
Vulnerabilities Webappsec->General
Software Application Security Development Code ruby on rails Rails
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.