
Ruby on Rails SQL Injection - lelf
http://seclists.org/oss-sec/2012/q2/504
======
Stratego
Doesn't it make more sense to post the security fix release?
[http://weblog.rubyonrails.org/2012/6/12/ann-
rails-3-2-6-has-...](http://weblog.rubyonrails.org/2012/6/12/ann-
rails-3-2-6-has-been-released/)

~~~
gurkendoktor
Not everyone is on the 3.2.x branch yet.

------
jtchang
Can someone enlighten me on how easy this SQL injection vulnerability is to
exploit?

I thought that SQL injection was "mostly" a thing of the past with newer
frameworks such as Rails and Django. I mean, short of concatenating your query
string together, it is much harder to set yourself up for failure.

~~~
lansing
Take a look at the test they added in the patch for an example of how the
exploit would go down.

~~~
kmf
Looks like two tests (test_where_error_with_hash and
test_where_with_table_name).

You can see those tests here:

[http://seclists.org/oss-sec/2012/q2/att-504/3-2-sql-
injectio...](http://seclists.org/oss-sec/2012/q2/att-504/3-2-sql-
injection.patch)

(this is for 3.2, you can change the patch name for 3.1, etc.)

------
mhartl
Thanks for the heads-up. I've updated the Rails Tutorial book accordingly.

~~~
graeme
For those of us following the tutorial, is the gemfile the only thing that
changed?:

    
    
        gem 'rails', '3.2.6'
    

I also had to run "bundle update railties" to fix a couple of dependences.

~~~
mhartl
Yes, the relevant change is in the Gemfile for each example project. Running

    
    
      $ bundle update rails
      $ bundle install
    

should bring you up to speed.

------
BadassFractal
Wasn't 3.2.4 specifically released a few weeks ago to address that very same
SQL injection vulnerability? Is this a regression?

~~~
dutchbrit
I was about to say, I swear I read an exact same vulnerability a few
days/weeks ago, also in regards to the where statement.

------
danso
I saw this post last night and assumed it was the same vulnerability from a
week ago.

Thanks to everyone who upvoted and made the comment that it requires a whole
new patch/upgrade, I would've missed it otherwise.

This is probably a case in which editorializing the submission title ("This is
brand new from last week") would've been a good service

~~~
oops
FYI you can get Rails security alerts directly to your inbox via
<http://groups.google.com/group/rubyonrails-security>

------
klapinat0r
<http://news.ycombinator.com/item?id=4052807>

~~~
sanxiyn
That was CVE-2012-2661. This one states:

CVE-2012-2695

Please note, this vulnerability is a variant of CVE-2012-2661, even if you
upgraded to address that issue, you must take action again.

~~~
look_lookatme
This vulnerability also adds 2.3 as an affected version.

------
benmmurphy
I have an article on these issues but mostly focusing on the ones fixed in
3.2.4/3.2.5. Article is a bit weird because it was written before 3.2.4 and I
thought some of the issues were user problems rather than framework problems.

[http://benmmurphy.github.com/blog/2012/05/15/abusing-
dynamic...](http://benmmurphy.github.com/blog/2012/05/15/abusing-dynamic-
types-for-fun-and-profit/)

------
scosman
second in a month? I stopped using rails in favour of sintra+activerecord.
Active record might need to go next :(

~~~
thibaut_barrere
I'm using both Sinatra and Rails, but I would not advise someone to switch to
Sinatra because Rails has more "fixed vulnerabilities".

Around me there are many times more Rails apps than Sinatra apps. I do believe
that the increased exposure of Rails makes it more likely to detect
vulnerabilities over there.

------
Toshio
I've looked at this and a few other ActiveRecord vulnerabilities that look
arcane at first sight, but the simplest solution that covers all of them is to
first check whether params[:something] is nil and refuse to do any DB stuff if
it is, and second to explicitly convert all of your params[:something] input
to the types of data you were expecting, using to_i, to_s or to_f.
Additionally, if using where clauses, strip the input of all apostrophes or
double quotes. I don't think there would be anything left to exploit if
everybody were to adopt this semi-paranoid approach to protecting your code
from bad input.

~~~
telent
> strip the input of all apostrophes or double quotes.

This approach will be a hard sell for Father O'Reilly and Dwight David "Ike"
Eisenhower

------
sirfried
how lame, do AR devs need someone to remind them about bind variables/params ?

~~~
Robin_Message
(rant) Since Rails devs don't appear to believe in databases (and to be fair,
if I was targeting MySQL version 3 I'm not sure I would believe in them much
either), they don't bother using database features for binding. Instead having
their own half baked (well, it 90% baked now, but it still has the occasional
squishy bit) binding system.

Same for validations, foreign keys, primary keys, indexes, enumerations, etc.
(/rant)

~~~
benmmurphy
the places where these sql injections were happening wouldn't be prevented
from traditional sql bindings which are applied to parts of the where clause
or set values. in JDBC land i don't think you can do "SHOW TABLES FROM ? WHERE
...."

