SQL Injection Vulnerability in Ruby on Rails; affects all versions • Hacker News Board

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#131

Post by dalke » Thu, Jan 03, 2013, 1:26 AM UTC

josh2600 wrote: post #115

tptacek wrote: post #44

Earlier quoted context omitted.

Blue boxing predates 5ESS switches; 5ESS was notoriously the switch you couldn't blue-box.

Oh really? I always thought SS7 was the first switch to move to out of band. What's the last blueBox-able switch?

Let's see. Phrack Volume Three, Issue 25 says "In March of 1982, the 5ESS switch first went into operation."

Esquire published "Secrets of the Little Blue Box" in the October 1971 issue of Esquire, based on the phone system MF design from the 1950s/1960s. That means blue boxing started at least 15 years before 5ESS, as tptacek pointed out.

The 1987 Phreakers Manual (http://fringe.davesource.com/Fringe/Hacking/Phreaking/Phreak... ) says "Blue boxing becomes harder as all Bell switching and transmission facilities go under to CCIS. Then to further complicate things, digital microwave, fiber optic, and satellite transmission are all coming to be digital and do not recognize 2600hz for the hang up signal. I predict that around 1990, blue boxes will be obsolete from all major cities."

The 2600 FAQ, Section C-07, says (the earliest date I found for this was August 9, 1993): "Because of ESS Blue boxing is impossible". This is incorrect. ... While the advent of ESS (and other electronic switches) has made the blue boxers task a bit more difficult, ESS is not the reason most of you are unable to blue box. The main culprit is the "forward audio mute" feature of CCIS (out of band signalling). ... So for the clever amongst you, you must somehow get yourself to the 1000's of trunks out there that still utilize MF signalling but bypass/disable the CCIS audio mute problem.

I don't know the switch models enough to say if it was exactly 5ESS, but everything suggests that that is the case.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#132

Post by venus » Thu, Jan 03, 2013, 1:26 AM UTC

The overreaction on this page is ridiculous. Has anyone actually read the steps required to exploit this vulnerability?

You do know that to be able to exploit it you have to know the application's secret key, so you can create your own malicious encrypted session cookie that includes hashes instead of strings for the auth token lookup?

You do know that if someone has your app's secret key they can just write whatever they want into the session cookie, instantly compromising a large number of apps anyway? That's the whole point of the secret key!

This is an obscure issue which can be used to get around one layer of defense in rails security. It could never get around all of them. It requires intimate in-depth knowledge of the app to even attempt the exploit. Sure, it's a bug, and it's not to be taken lightly, but the howls of derision here are totally out of proportion.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#133

Post by chrismsnz » Thu, Jan 03, 2013, 1:29 AM UTC

venus wrote: post #132

The overreaction on this page is ridiculous. Has anyone actually read the steps required to exploit this vulnerability? You do know that to be able to exploit it you have to know the application's secret key, so you can create your own malicious encrypted session cookie that includes hashes instead of strings for the auth token lookup? You do know that if someone has your app's secret key they can just write whatever…

Please provide a source for your claims.

From looking at it, it seems that ANY HTTP parameter (e.g. POST or GET - which are completely user-controlled) can be manipulated if you know how it's going to be used in the code, e.g. an obvious object ID.

EDIT: tenderlove sets it straight below

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#134

Post by martinced » Thu, Jan 03, 2013, 1:32 AM UTC

One could lament that the real issue is the (maybe not so) accidental complexity (and hidden deep down complexity lies insecurity) that results when you're using utter non-sense like an ORM.

The very concept of an ORM is broken. I know most devs don't know SQL well enough to do more code directly from SQL and I know most devs don't know anything else than SQL... But it's a bit sad to see all these "frameworks" tailored to the masses.

dev: "I want objects. I don't really understand set theory but I still want SQL because it's all I know."

chef: OK, here's a framework doing nearly everything from you.

Seriously guys. Mixing orthogonal concepts and posting provocatively titled blog entries like "OO and SQL aren't orthogonal concepts, there's no mismatch impedance" ain't going to help.

The only thing this creates is a lot of needless complexity and, of course, there shall always be major SNAFU like this one.

Maybe, just maybe, that we could realize that if the reader is set to "from now on do not eval anymore" code shall not be eval'ed? And maybe, just maybe, that we could realize that if you're not using SQL you're not subject to these monthly SQL injections issues?

How far does the SNAFU need to go for you to consider that OO + SQL is actually a very, very poor mix?

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#135

Post by [deleted] » Thu, Jan 03, 2013, 1:32 AM UTC

numbsafari wrote: post #96

phillmv wrote: post #87

Earlier quoted context omitted.

>The fact that this keeps happening on Rails is the #1 reason I haven't bothered to take the time to do anything real with it. I don't have the time to read the code for the framework and I don't trust that it's written with security in mind. What frameworks do you use? Have you performed your own audit?

Totally fair question. I personally prefer not to use ORMs for this specific reason: they are typically way too complicated to be able to plow through the code in any reasonable way. It's also generally not that hard to design your application in such a way that using a minimalist "ORM-ish" layer of your own making isn't exactly a waste of time. I've also found that they rarely follow these best practices (it's madde…

[deleted]

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#136

Post by venus » Thu, Jan 03, 2013, 1:33 AM UTC

chrismsnz wrote: post #133

venus wrote: post #132

The overreaction on this page is ridiculous. Has anyone actually read the steps required to exploit this vulnerability? You do know that to be able to exploit it you have to know the application's secret key, so you can create your own malicious encrypted session cookie that includes hashes instead of strings for the auth token lookup? You do know that if someone has your app's secret key they can just write whatever…

Please provide a source for your claims. From looking at it, it seems that ANY HTTP parameter (e.g. POST or GET - which are completely user-controlled) can be manipulated if you know how it's going to be used in the code, e.g. an obvious object ID. EDIT: tenderlove sets it straight below

Sure. Here is the exploit: https://github.com/binarylogic/authlogic/pull/341

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#137

Post by dhimes » Thu, Jan 03, 2013, 1:34 AM UTC

numbsafari wrote: post #96

phillmv wrote: post #87

Earlier quoted context omitted.

>The fact that this keeps happening on Rails is the #1 reason I haven't bothered to take the time to do anything real with it. I don't have the time to read the code for the framework and I don't trust that it's written with security in mind. What frameworks do you use? Have you performed your own audit?

Totally fair question. I personally prefer not to use ORMs for this specific reason: they are typically way too complicated to be able to plow through the code in any reasonable way. It's also generally not that hard to design your application in such a way that using a minimalist "ORM-ish" layer of your own making isn't exactly a waste of time. I've also found that they rarely follow these best practices (it's madde…

I'm disturbed by the fact that you are getting downvoted (here and in another comment thread on this page), largely because I largely agree. I am not an expert by any means so I try to stay atop of "best practices," but what you are saying resonates with what I thought I understood. So if you are way wrong I'd love it if somebody would come out and definitively say so.

I am using my first framework (yiiframework) at the suggestion of another dev. I still do things like

  query(user_input){
     switch(user_input){
       case(x):
         do query_x;
         break;
       case(y):
         do query_y;
         break;
   ...
   }
   }

The other dev thinks I'm nuts, but I avoid a lot of worry with this. I may lose some performance I suppose...

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#138

Post by chrismsnz » Thu, Jan 03, 2013, 1:36 AM UTC

venus wrote: post #136

chrismsnz wrote: post #133

Earlier quoted context omitted.

Please provide a source for your claims. From looking at it, it seems that ANY HTTP parameter (e.g. POST or GET - which are completely user-controlled) can be manipulated if you know how it's going to be used in the code, e.g. an obvious object ID. EDIT: tenderlove sets it straight below

Sure. Here is the exploit: https://github.com/binarylogic/authlogic/pull/341

That's a bug/exploit in Authlogic, a third party library for rails, not rails.

However, that bug/exploit is based on the rails vuln and was patched in authlogic exactly how the Rails report instructed people to work around it (casting the parameter to a string).

Reading the actual report linked in the OP you'll see that generic and boilerplate code (e.g. the extremely common pattern: "Post.find_by_id(params[:id])") is going to be vulnerable to this bug.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#139

Post by tenderlove » Thu, Jan 03, 2013, 1:38 AM UTC

chrismsnz wrote: post #133

venus wrote: post #132

The overreaction on this page is ridiculous. Has anyone actually read the steps required to exploit this vulnerability? You do know that to be able to exploit it you have to know the application's secret key, so you can create your own malicious encrypted session cookie that includes hashes instead of strings for the auth token lookup? You do know that if someone has your app's secret key they can just write whatever…

Please provide a source for your claims. From looking at it, it seems that ANY HTTP parameter (e.g. POST or GET - which are completely user-controlled) can be manipulated if you know how it's going to be used in the code, e.g. an obvious object ID. EDIT: tenderlove sets it straight below

You need a way to inject symbols as hash keys. Normal parameter handling does not allow this, so you need a different way to exploit the bug. As venus says, session forging is one way. Regular parameter handling is not.

Re: SQL Injection Vulnerability in Ruby on Rails; affects all versions

#140

Post by icambron » Thu, Jan 03, 2013, 1:38 AM UTC

tptacek wrote: post #128

cheald wrote: post #69

Earlier quoted context omitted.

I'm pretty sure that the injection only works when you can forge a session because sessions may contain marshalled symbols, and the dynamic finders only accepted symbol option keys as valid. You can't get Rails to construct symbols out of a params hash. Is this a separate vulnerability?

You can get Rails to construct symbols out of a params hash in some cases.

Honest question: how?