Blog|Login|中文Deutsche日本語
January 11, 2013
 Ruby Gone Wild
Pin It

 

 

It has been recently discovered that the Ruby on Rails (RoR) environment suffer from certain parser vulnerabilities. The CVE-IDs associated with these vulnerabilities are CVE-2013-0155, CVE-2013-0156.

Both of the issues stem from RoR parser vulnerabilities. The handling of complex objects representations such as XML and JSON serialization formats, fails to address some scenarios raises several security issues.

What are the vulnerabilities mentioned?

CVE-2013-0156
In essence, the RoR parser can be told by the attacker to automatically instantiate complex objects of the YAML and Symbol type. These complex object instantiation may involve evaluating some arbitrary, attacker controlled, Ruby code. Some sources report they were able to abuse this vulnerability to run some arbitrary operating system (OS) commands.  This means once the attacker can basically own the server completely.

This vulnerability is Generic in the sense that it’s not related to a specific application running on top of RoR, but to the RoR infrastructure itself.

An example could be found on Rapid7’s blog.

 

CVE-2013-0155
Using JSON, an attacker can pass an array instead of the expected atomic type such as an integer or a string.

Abusing that vulnerability, the attacker can smuggle a NULL in one of the array elements, and bypass an application specific “IS NULL” check designed for atomic types, because the array contains other values besides the null.

Note that this vulnerability exploitation is very specific to the context of the application itself.

An example could be found on the Ruby On Rails Google Group here.

 

How to stay safe
In order to stay on the safe side of the lake, you should always harden your application from any unused capabilities in order to lower the risk.

A few steps to consider:

  1. Profile your application; only allow actions that are explicitly required. For example, if your application does not use XML/JSON, simply don’t allow that traffic. A WAF should have a capability to block access against “Unauthorized Request Content Type” with respect to the application profile.
  2. Blocking the creation of YAML or Symbol type in web messages. A simple WAF rule would stop that activity.
  3. For CVE-2013-0155 the logic is to simply to disallow null values to the specific vulnerable array parameters.

 

After thoughts
The Ruby on Rails vulnerabilities discovery prove the importance of White List security in the Web application world.  These issues show the importance of  only allowing what is specifically permitted and then specifically precluding known bad input values.


Comments

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

« Still Don't Like Our AV Study? A Response to The Critics | Main | Social Engineering Hits the Classifieds »

Find Us Online
RSS Feed - Subscribe Twitter Facebook iTunes LinkedIn YouTube
Authors
Monthly Archives
Email Subscription
Sign up here to receive our blog: