Why the Latest Rails Exploit Is Indicative of a Bigger Problem
blog.sdelements.com
Why the Latest Rails Exploit Is Indicative of a Bigger Problem
1–10 of 52 posts
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#2Google text version cache: http://webcache.googleusercontent.com/search?q=cache:9m5PdBh...
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#3Their server is down. Here's the content:
-- by Rohit Sethi on February 13, 2013 -- http://blog.sdelements.com/author/rohit/
The latest Rails security flaw [1] is example of a common anti-pattern. Ned Batchelder wrote an awesome post [2] explaining how a similar issue may also exist in Python’s YAML parser [3]. 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 [4]; or dynamically assign user-supplied parameters to server-side variables [5] (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 [6] 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 [7] 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 [8] 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 [9]
[1] http://www.zweitag.de/en/blog/ruby-on-rails-vulnerable-to-ma... [2] http://nedbatchelder.com/blog/201302/war_is_peace.html [3] http://pypi.python.org/pypi/PyYAML [4] http://labs.securitycompass.com/tutorials/xslt-command-execu... [5] http://www.codeproject.com/Articles/471784/Exploiting-Micros... [6] https://www.owasp.org/index.php/Category:OWASP_Security_Anal... [7] http://blog.sdelements.com/raising-the-bar-on-application-se... [8] http://xml.apache.org/xalan-j/extensions.html [9] https://groups.google.com/forum/?hl=en&fromgroups#!forum...
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#4Their server is down. Here's the content: -- by Rohit Sethi on February 13, 2013 -- http://blog.sdelements.com/author/rohit/ The latest Rails security flaw [1] is example of a common anti-pattern. Ned Batchelder wrote an awesome post [2] explaining how a similar issue may also exist in Python’s YAML parser [3]. Looking at these vulnerabilities, I am reminded of similar flaws in other frameworks and libraries. The iss…
Now that's an interesting idea: developer preferences for extensibility mechanisms in libraries. Anyone know of example libraries shipping with that capability?
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#5Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#6Their server is down. Here's the content: -- by Rohit Sethi on February 13, 2013 -- http://blog.sdelements.com/author/rohit/ The latest Rails security flaw [1] is example of a common anti-pattern. Ned Batchelder wrote an awesome post [2] explaining how a similar issue may also exist in Python’s YAML parser [3]. Looking at these vulnerabilities, I am reminded of similar flaws in other frameworks and libraries. The iss…
Now that's an interesting idea: developer preferences for extensibility mechanisms in libraries. Anyone know of example libraries shipping with that capability?
An interesting question is why do developers prefer runtime extensibility over compile time extensibility? Runtime extensibility trusts whatever happens to come on the wire, compile time extensibility explicitly whitelists the exact set of functionality the server will support.
Hypothesis: developers don't like code generation. Partly because build systems are unreasonably difficult to tweak, partly because debugging tools are too crude to handle code generation graciously.
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#7Their server is down. Here's the content: -- by Rohit Sethi on February 13, 2013 -- http://blog.sdelements.com/author/rohit/ The latest Rails security flaw [1] is example of a common anti-pattern. Ned Batchelder wrote an awesome post [2] explaining how a similar issue may also exist in Python’s YAML parser [3]. Looking at these vulnerabilities, I am reminded of similar flaws in other frameworks and libraries. The iss…
Doesn't this get into the issue of whether XML dependency injection is a good idea? All of the wiring and some logic is built up in some files that are outside of the build/compilation process. Doing "proper dependency injection" (quotes for sarcasm) to me has always made me worry that I've lost control of how my application works, and somehow based on the right XML/JSON/etc config magic it will work perfectly and meet all security standards.
Maybe I'm just too jaded...
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#8Earlier quoted context omitted.
Now that's an interesting idea: developer preferences for extensibility mechanisms in libraries. Anyone know of example libraries shipping with that capability?
An interesting question is why do developers prefer runtime extensibility over compile time extensibility? Runtime extensibility trusts whatever happens to come on the wire, compile time extensibility explicitly whitelists the exact set of functionality the server will support. Hypothesis: developers don't like code generation. Partly because build systems are unreasonably difficult to tweak, partly because debugging…
Yeah, that's a fair assessment - compile time code generation is unnecessarily painful in many popular languages. Often even if there is a facility for it built in (e.g. C preprocessor macros, C++ templates), it's less powerful and more complex than it needs to be because the designers of the language for some reason decided not to just let you use the same language at compile time that you use at runtime.
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#9Their server is down. Here's the content: -- by Rohit Sethi on February 13, 2013 -- http://blog.sdelements.com/author/rohit/ The latest Rails security flaw [1] is example of a common anti-pattern. Ned Batchelder wrote an awesome post [2] explaining how a similar issue may also exist in Python’s YAML parser [3]. Looking at these vulnerabilities, I am reminded of similar flaws in other frameworks and libraries. The iss…
Doesn't this get into the issue of whether XML dependency injection is a good idea? All of the wiring and some logic is built up in some files that are outside of the build/compilation process. Doing "proper dependency injection" (quotes for sarcasm) to me has always made me worry that I've lost control of how my application works, and somehow based on the right XML/JSON/etc config magic it will work perfectly and me…
Do your remote users have any control over those files? Probably not, or at least, probably not on purpose. The problem here is highly extensible systems that consume some user-sourced data and ultimately contain some sort of path whereby the user is essentially running a program with some set of capabilities they are not supposed to have. (Many of these attacks have resulted in arbitrary code execution, but weaker forms are possible, where perhaps you can only instantiate a class that results in some file being created on disk with arbitrary contents, or reads from it, or something.)
Many of these systems are written with the use case in the developer's mind where the data can be trusted to some degree, because perhaps they assume it's going to be read only by the program that generated it and only viewed by the user who already owns the computer, etc. In some sense the error only occurs when one takes this sort of software and then exposes it to the network, but it can be hard to realize when you... or somebody buried three layers deep in $YOUR_FAVORITE_FRAMEWORK... has done that.
Re: Why the Latest Rails Exploit Is Indicative of a Bigger Problem
#10Serious developers take an interest in making things as simple as possible, ideally each piece have singular responsibilities, and no magic. Software engineering is hard, and it is heartening to see more people realise and promote awareness of some of the more dangerous anti-patterns we see in frameworks like Rails.
The problem isn't "magic" per se, and the problematic components already have very clearly defined singular responsibilities (an API doesn't get much simpler than "dump" and "parse").
Security problems often happen when two components that are perfectly safe in their original contexts are tied together in a way that their designers didn't intend. These parser problems are examples of that.
So it's actually a good thing that frameworks like Rails try to tie together many components for you "magically". The integration of all those little simple pieces is always a chance to screw up security. It's better to do that hard work once, collaboratively as a community, than to have every developer make those risky choices separately every single time.
It's the same cost/benefit analysis that explains why you should never roll your own crypto. Anybody can make a system that's "secure" enough to keep themselves from breaking it, but that's not nearly good enough. You increase security by increasing scrutiny.