Forgot your password?
typodupeerror
Programming Ruby Security IT

All Ruby On Rails Versions Suffer SQL Injection Flaw 81

Posted by timothy
from the this-tunnel-under-construction dept.
Trailrunner7 writes with the news as posted at Threatpost (based on this advisory) that "All of the current versions of the Ruby on Rails Web framework have a SQL injection vulnerability that could allow an attacker to inject code into Web applications. The vulnerability is a serious one given the widespread use of the popular framework for developing Web apps, and the maintainers of Ruby on Rails have released new versions that fix the flaw, versions 3.2.10, 3.1.9 and 3.0.18. The advisory recommends that users running affected versions, which is essentially anyone using Ruby on Rails, upgrade immediately to one of the fixed versions, 3.2.10, 3.1.9 or 3.0.18. The vulnerability lies specifically in the Ruby on Rails framework, and its presence doesn't mean that all of the apps developed on vulnerable versions are susceptible to the bug."
This discussion has been archived. No new comments can be posted.

All Ruby On Rails Versions Suffer SQL Injection Flaw

Comments Filter:
  • Pthhhhttpppt (Score:5, Informative)

    by Anonymous Coward on Thursday January 03, 2013 @12:50PM (#42463377)

    Had me freaked out for a second, but then I RTFA (on accident I swear). Nothing to see here, please move along. If they have your HMAC key you are doing it wrong.

    "So to inject arbitrary SQL, you need to tamper with the cookie, which requires the HMAC key. The HMAC key is the so-called session secret. As the name implies, it is supposed to be secret. Rails generates a random 512-bit secret upon project creation. This is why most Rails apps that are running Authlogic are not exploitable: the attacker does not know the secret. Open source Rails apps however can form a problem. Many of them come with a default session secret, but the user never customizes them, so all those instances end up using the same HMAC key, making them very easily exploitable. Of course, in this case the operator have to worry about more than just SQL injection. If the HMAC key is known then anybody can send fake credentials to the app."

  • Hold your horses (Score:5, Informative)

    by bimozx (2689433) on Thursday January 03, 2013 @12:51PM (#42463409)
    rails sql injection vulnerability hold your horses here are the facts [phusion.nl]

    Too briefly re-iterate certain main important points in the article.
    • - It does not mean all unupgraded Rails apps are suddenly widely vulnerable.
    • - It does not mean Rails doesnâ(TM)t escape SQL inputs.
    • - It does not mean Rails doesnâ(TM)t provide parameterized SQL APIs.
    • - It does not mean Rails encourages code that are inherently prone to SQL injection. The code should be safe but due to a subtlety was not. This has been fixed.
  • by Desler (1608317) on Thursday January 03, 2013 @12:54PM (#42463455)

    No, the flaw applies if you are not using authlogic.

    This is why most Rails apps that are running Authlogic are not exploitable

  • More information (Score:5, Informative)

    by FooBarWidget (556006) on Thursday January 03, 2013 @12:54PM (#42463463)

    This article [phusion.nl] explains what the vulnerability is, how it is triggered, how severe it is and what the facts are.

  • by Serious Callers Only (1022605) on Thursday January 03, 2013 @01:28PM (#42463923)

    When it's a major security flaw?

    According to the article, this is not in fact a major security flaw, unless you have made your secret session key (HMAC) for the app public, and are using old style finder methods like find_by_id(2) etc. For a start the attacker has to know your HMAC - this is randomly generated when creating a rails app, and is not supposed to be publicly disclosed, though if your app is open source and you forgot to change it and left it in a public repo, it is possible someone could find it. The vast majority of rails apps this is not going to apply to, and there are obvious reasons you shouldn't make your session signing key public anyway.

    So it looks like this is a bug which the majority of rails users won't have to worry about, but it's good that they fixed it.

  • by dririan (1131339) on Thursday January 03, 2013 @01:28PM (#42463925)

    A known exploitable scenario is when all of the following applies:
    1. You're using Authlogic (a third party but popular authentication library).
    2. You must know the session secret token.

    http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/ [phusion.nl]

    Seems like you are mistaken. I believe they were saying that merely using Authlogic doesn't automatically make you vulnerable, but you need to be using it to be vulnerable.

  • Re:Ruby Injection (Score:4, Informative)

    by johnw (3725) on Thursday January 03, 2013 @04:32PM (#42466343)

    This is an arbitrary SQL injection vulnerability. According to the advisory, it is in the very core of the Active Record. Anyone who has ever programmed for RoR has definitely used the following:

            Post.find_by_id(params[:id])

    This is the standard way of finding a DB record by ID, and advised like this in all RoR books. It is one of the most fundamental calls in the whole framework.

    Not true - the more natural (and non-vulnerable) way to write this is:

            Post.find(params[:id])

    and that's the way normally recommended in books on the subject.

All warranty and guarantee clauses become null and void upon payment of invoice.

Working...