

Why the Latest Rails Exploit Is Indicative of a Bigger Problem - hhaidar
http://blog.sdelements.com/why-the-latest-rails-exploit-is-indicative-of-a-bigger-problem/

======
dfcarney
Their 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...](http://www.zweitag.de/en/blog/ruby-on-rails-vulnerable-to-mass-
assignment-and-sql-injection) [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...](http://labs.securitycompass.com/tutorials/xslt-command-execution-
exploit/) [5] [http://www.codeproject.com/Articles/471784/Exploiting-
Micros...](http://www.codeproject.com/Articles/471784/Exploiting-Microsoft-
MVC-vulnerabilities-using-OWA) [6]
[https://www.owasp.org/index.php/Category:OWASP_Security_Anal...](https://www.owasp.org/index.php/Category:OWASP_Security_Analysis_of_Core_J2EE_Design_Patterns_Project/PresentationTier#Avoid_3)
[7] [http://blog.sdelements.com/raising-the-bar-on-application-
se...](http://blog.sdelements.com/raising-the-bar-on-application-security-due-
diligence/) [8] <http://xml.apache.org/xalan-j/extensions.html> [9]
[https://groups.google.com/forum/?hl=en&fromgroups#!forum...](https://groups.google.com/forum/?hl=en&fromgroups#!forum/rubyonrails-
security)

~~~
typicalrunt
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...

~~~
jerf
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.

------
ehsanf
I believe over-engineering is also a culprit here. We had a similar situation
in JSON handling in browser. Some over engineered feature allows custom
objects to replace built in object for lists, allowing XSS through JSON
parser. The solution was to make every REST API to start with a top level
dictionary object. It just sounds arbitrary over engineering!!

~~~
astrodust
Why can't there be a set of parsers for YAML, JSON, and XML that are tested,
abused, and audited aggressively so that your interchange formats don't become
attack vectors?

The current state of having a half dozen of each of these is complete chaos.
Presumably nobody thinks they're accountable because everyone has the option
of using another package instead if they're not happy, basically passing the
hot-potato constantly.

Is there a non-Ruby project that has a good implementation of these worth
studying?

------
eyko
Google text version cache:
[http://webcache.googleusercontent.com/search?q=cache:9m5PdBh...](http://webcache.googleusercontent.com/search?q=cache:9m5PdBh6sEkJ:blog.sdelements.com/why-
the-latest-rails-exploit-is-indicative-of-a-bigger-
problem/&hl=en&tbo=d&gl=uk&strip=1)

------
amalag
I also don't understand why all parsing of user input needs to have YAML
turned on by default. All this stuff should be turned off. I think it is a
fundamental design choice that has to be looked at.

~~~
ehsanf
We should call it "insecurity by default" (in contrast to insecurity by
design). A major problem is that nobody takes responsibility or pays attention
for default choices.

A ton of packages have default choices that are inherently bad/insecure (mail
servers listening on all interfaces by default, SSH servers accepting root
login by default, and so on). Packaging is just as important as development.

------
static_typed
Serious 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.

~~~
bithive123
There is no magic in Rails, it's just Ruby code. There will always be APIs
that shouldn't be given untrusted data. When this happens anyway, calling it
an "anti-pattern" does not mean you have perceived some kind of systemic
fundamental flaw in the framework. That's just a transparently self-serving
way for you to feel superior because after all you're a "serious developer".

~~~
metaphorm
magic is just a shorthand for "code executed automatically, behind the scenes,
based on some reasonable assumptions". Rails does a whole lot of this type of
magic, as does basically every framework.

~~~
bithive123
Then it's a meaningless term. The fact that iTunes doesn't need to ship with
drivers for my sound card is the same kind of "magic".

~~~
metaphorm
this isn't a good analogy. Rails is a software development framework whose
users are programmers. iTunes is a media player whose users are non-technical.
in other words Rails is a tool while iTunes is a finished product. you
wouldn't compare a hammer with a cabinet, would you?

if zero-framework development is a hammer, then development with a framework
is a power-tool combination drill/hammer/driver. the power-tool does so much
more then the basic tool that it feels "magical". its not a meaningless term
then. its a description of the power of the tool.

