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

21–30 of 220 posts

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

#21

Post by VMG »

dmix wrote: post #11
danso wrote: post #2

FWIW, this is the third time in seven months that Rails had to issue a patch related to how ActiveRecord handles method parameters. 3.2.6 (June 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... 3.2.4 (May 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

I've always found Rails to be easy to secure compared to most other frameworks. I think the defaults are all pretty secure. I'd prefer having constant security patches. It shows people are still constantly testing it for vulnerabilities.

by that logic php is rock solid

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

#22

Post by [deleted] »

jtchang wrote: post #5

I am mostly a Django programmer so excuse my ignorance of rails. How does this keep happening? In Django you would do: Post.objects.get(pk=request.GET['id']) There really is no way to do SQL injection this way. This line in rails looks almost exactly like how you would do it in Django: Post.find_by_id(params[:id]) Also this seems really serious. It's not like a edge case where you need to grab a post by id. This is p…

[deleted]

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

#23

Post by jroes »

rst wrote: post #19
clamstar wrote: post #14

You need the contents of secret_token.rb to exploit this (via a forged session). This makes it much more of a danger to OSS projects than to those in the closed source space. It's not just a SQL Injection vulnerability. With that secret token, you can set any session value you like.

Different vuln; this one has nothing to do with session cookies.

tenderlove mentions it has been assigned CVE-2012-5664. This is that CVE:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5664

It references two articles that require session secrets.

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

#25

Post by charliesome »

danso wrote: post #2

FWIW, this is the third time in seven months that Rails had to issue a patch related to how ActiveRecord handles method parameters. 3.2.6 (June 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... 3.2.4 (May 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

History seems to keep reminding us that in-band signalling is a convenient idea fraught with danger.

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

#26

Post by latortuga »

oomkiller wrote: post #18

It seems like this is being conflated with the session token issue? How do you submit params with symbolized keys? Hashes are easy enough, but it doesn't work with hashes that have strings as keys, only symbols. EDIT: Just to be clear, tenderlove (Ruby/Rails committer) confirms that you do not need to edit the session to exploit this ( http://news.ycombinator.com/item?id=4999767 ). It's still unclear how it is possib…

Rails param parsing automatically converts all param keys to symbols.

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

#27

Post by elbear »

charliesome wrote: post #13
codewright wrote: post #8

Earlier quoted context omitted.

Btw, this applies for my (Python) Flask apps using MongoDB ORMs. They escape the inputs. What the hell is going on with ActiveRecord?

The main issue stems from Ruby using the last positional parameter to pass a hash representing keyword arguments. This means if there's only one parameter, and someone can sneak a Hash in there where you weren't expecting it (params parsing, request body parsing, etc) then they can end up passing dodgy 'keyword arguments' into your method call.

In Python, the parameter escaping is done at the level of the database driver not the ORM. Isn't this the case with Ruby?

Of course, you could use the driver incorrectly to risk SQL injection, but that is a very obvious mistake that no experienced developer would make.

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

#28

Post by nbpoole »

jroes wrote: post #17
clamstar wrote: post #14

You need the contents of secret_token.rb to exploit this (via a forged session). This makes it much more of a danger to OSS projects than to those in the closed source space. It's not just a SQL Injection vulnerability. With that secret token, you can set any session value you like.

This is how I understand the issue as well. Many people in this thread are commenting about massive dangers, but I don't think anyone has bothered to actually read the references in the CVE. Also, even open source projects typically ensure or recommend that the secret token be regenerated when using in production environments.

I think the CVE description is inaccurate in this case. Check out the Rails security email list description, which never mentions sessions.

https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

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

#29

Post by roc »

benlower wrote: post #12

So does the fact that "Rails is Omakase" ( http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) mean that the chef tried to serve Fugu ( http://en.wikipedia.org/wiki/Fugu ) but cut it wrong?

No, it just means that any chef serving Fugu can cut it wrong.

So when someone offers to do something inherently dangerous on your behalf, you should be incredibly deliberate.

There's no shortage of frameworks, platforms and libraries that have been bit (repeatedly) by SQL injection.

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

#30

Post by josh2600 »

charliesome wrote: post #25
danso wrote: post #2

FWIW, this is the third time in seven months that Rails had to issue a patch related to how ActiveRecord handles method parameters. 3.2.6 (June 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... 3.2.4 (May 2012) https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

History seems to keep reminding us that in-band signalling is a convenient idea fraught with danger.

Look no further than the deprecated 5ESS switches which used to give up free calls due to 2600hz tones being signaled inband.

Ask Steve Jobs and Woz about BlueBoxes; you need look no further to see the inherent dangers on inband signaling.

Slightly off-topic, but still relevant IMHO.

Post reply on HN