Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQL Injection Vulnerability in Ruby on Rails; affects all versions

groups.google.com

Post reply on HN
Print view View original

171–180 of 220 posts

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

#171

Post by tptacek »

ufo wrote: post #169
cheald wrote: post #163

Earlier quoted context omitted.

Seconding icambron - how? Because I've been up and down that code and can't see any way to do it. Frankly, I don't think it's possible, because otherwise you would have a trivial DOS vector into any Rails application.

How is this a DOS vector? Would passing a symbol instead of a string in the parameters cause the app to crash?

No; the theory behind that attack is, Rails doesn't GC symbols, so you could just repeatedly stuff requests that created new symbols until memory was exhausted. I don't care about that attack (there are others like it), but it's viable.

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

#172

Post by cheald »

ufo wrote: post #169
cheald wrote: post #163

Earlier quoted context omitted.

Seconding icambron - how? Because I've been up and down that code and can't see any way to do it. Frankly, I don't think it's possible, because otherwise you would have a trivial DOS vector into any Rails application.

How is this a DOS vector? Would passing a symbol instead of a string in the parameters cause the app to crash?

Symbols are interned and never garbage collected, so if you can cause an app to create arbitrary symbols, you can cause it to use up all the RAM on the machine and throw it into swap, effectively killing its ability to respond to requests in any kind of timely fashion.

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

#173

Post by ufo »

amorphid wrote: post #76
hayksaakian wrote: post #66

Earlier quoted context omitted.

That's what I was referring to. Do mongomapper and mongoid have this problem?

On the bright side you need not fear this bug for your apps using MongoDB. Mongoid and MongoMapper do not use SQL, so there should be no SQL injection problems using those two options.

The root cause of the bug here is not sql injection. Its that one of the query functions is overloaded to do different things depending on what datatype you pass to it and that the user can manipulate that datatype (for example, by passing an object in a part of a JSON message that would usully conatin a string). Of course, this is only really serious if one of the overloads gices too much power (in this vulnerability's case it would let you run an arbitrary query)

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

#174

Post by cheald »

tptacek wrote: post #170
cheald wrote: post #163

Earlier quoted context omitted.

Seconding icambron - how? Because I've been up and down that code and can't see any way to do it. Frankly, I don't think it's possible, because otherwise you would have a trivial DOS vector into any Rails application.

It is possible, but not straightforwardly. There isn't a code path I know of that converts param keys to symbols. (I wouldn't have said it was possible unless I had a curl line that did it, for what it's worth.)

You're the expert here, but that's really disturbing. Is it fixable?

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

#175

Post by venus »

jtchang wrote: post #145
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…

It is not an overreaction. This is a much more subtle SQL injection. I believe the takeaway is that too much magic is a bad thing when it obscures the underlying behavior. Post.find_by_id( ) accepts an argument. Here are some normal assumptions: 1. It might only take a number 2. The method might coerce it to a string or integer for you 3. The method might not coerce it. 4. The method might throw an error if it isn't…

I happen to agree with you that (5) is a magic bridge too far, but that's a different discussion.

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

#176

Post by jeltz »

sontek wrote: post #161
jeltz wrote: post #144

Earlier quoted context omitted.

The problem is that ORMs like ActiveRecord really are just domain specific languages for building queries. If these DSLs use inband are carelessly constructed (e.g. they use some form of inband signaling) you can do the injection attack against the actual ORM code and make it build queries the author of the code did not intend.

http://sqlalchemy.org/ is an ORM and does not have these security issues. So it can be done.

I did not say otherwise. I said that ORMs may be vulnerable if they are carelessly constructed.

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

#177

Post by numbsafari »

venus wrote: post #141
chrismsnz wrote: post #138

Earlier quoted context omitted.

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])") i…

The linked pull request described a method for getting unescaped code into the application so the issue with find_by_id might be exploited. Have you got another way of getting unescaped code into the application such that this issue might be exploited? If so, the core team will be very, very interested to hear from you.

I've been going through the code for ActiveRecord and now AuthLogic. I'm admittedly not well versed in Ruby.

However from the description of the vulnerability found at [1], it would appear as though the cookie value can be set to a Ruby string value that is then parsed by server to produce a Ruby Hash value (rather than the AuthLogic plugin's assumed string value).

Is the eval() of the cookie value done by Rails or is it done by AuthLogic? Is that a potential security vulnerability in itself?

[1]http://phenoelit.org/blog/archives/2012/12/21/let_me_github_...

edit: forgot the URL

edit2: nvm ... apparently it's using the Ruby Marshal API, not an eval()-type call.

http://stackoverflow.com/a/2241740

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

#178

Post by mattmcknight »

jtchang wrote: post #46
[deleted] wrote: post #22

Earlier quoted context omitted.

[deleted]

I'm sorry but this is braindead. I'm sure there are valid use cases but optimize for the most common one: find_by_id accepts a single argument, the ID of the object you want to find. That is why Python has kwargs. Those two stars stand out like a sore thumb and when you are passing positional arguments in the form of a hash it is pretty apparent.

that would be called .find(id) - accepts a single argument of an id. This is the canonical way to retrieve by id.

find_by_id, find_by_name, etc. aren't really methods, they trigger calls to method_missing which interprets the code to generate SQL. It's a "neat" feature, but one which I've only used once or twice in 6 years of Rails development.

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

#179

Post by graue »

SoftwareMaven wrote: post #157
paulgb wrote: post #153

Earlier quoted context omitted.

354 matches. https://github.com/search?utf8=%E2%9C%93&q=secret_token....

That's an interesting issue (Django has the same issue with its SECRET_KEY). If you have an open-source project that utilizes these kinds of technologies, you need to keep your secret key secret . As it says in the Django settings: "Make this unique, and don't share it with anybody." Your web application's security depends on it!

Incidentally, this is one reason why the 12-factor app methodology stores configuration in environment variables, not source files. http://www.12factor.net/config

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

#180

Post by [deleted] »

numbsafari wrote: post #177
venus wrote: post #141

Earlier quoted context omitted.

The linked pull request described a method for getting unescaped code into the application so the issue with find_by_id might be exploited. Have you got another way of getting unescaped code into the application such that this issue might be exploited? If so, the core team will be very, very interested to hear from you.

I've been going through the code for ActiveRecord and now AuthLogic. I'm admittedly not well versed in Ruby. However from the description of the vulnerability found at [1], it would appear as though the cookie value can be set to a Ruby string value that is then parsed by server to produce a Ruby Hash value (rather than the AuthLogic plugin's assumed string value). Is the eval() of the cookie value done by Rails or i…

[deleted]
Post reply on HN