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:
  • I suppose their advice for those running legacy deployments of Rails 2.x apps is to upgrade to 3.x. Rad.

  • Correct me if I'm wrong, but in Ruby on RAILS, doesn't the database calls execute through a ruby function? So you are not injecting SQL, but some ruby that then executes SQL.
    • by Anonymous Coward
      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.

      Now, according to the advisory, the automatic type conversion (again, one of the core features of Ruby) can be exploited to produce an SQL injection from this.

      • Actually that's not true, since 3.0 at least the default style (from scaffolds for example) has been Post.find(params[:id]), many people don't use dynamic finders at all, as you can use where(...) and scopes instead.

        Also, according to the advisory, the HMAC is required, that's really very unusual and important.

      • 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.

  • 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."

    • Re:Pthhhhttpppt (Score:5, Insightful)

      by larry bagina (561269) on Thursday January 03, 2013 @01:13PM (#42463689) Journal
      Joe Public shouldn't have your HMAC key, but Joe Disgruntled Former Employee/Consultant might. And he might also be disgruntled.
      • That's akin to not changing system passwords after someone leaves the department.
        • Right, but the HMAC session key is used to encrypt user sessions. Change the key, and all the old sessions become invalid. Your suggestion is akin to saying, after someone stops working at your company, every user of the company's website should get logged out.

    • Forgive me if this is a silly question, but isnt "sending fake credentials to the front-end app" significantly less worrisome than "can send arbitrary SQL commands to the backend DB"?

      • Not really no, as they could impersonate an admin account and use that to execute whatever commands they wish.

      • Forgive me if this is a silly question, but isnt "sending fake credentials to the front-end app" significantly less worrisome than "can send arbitrary SQL commands to the backend DB"?

        It shouldn't really be, because if the backend DB is secured properly, "can send fake credentials to the front-end app" and "can explot the front-end app to send arbitrary SQL to the back-end DB" should be exactly equivalent, since the backend DB should only allow the front-end app's account to do things that the front-end ap

  • 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.
  • 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 Ksevio (865461)
      So it looks like it centers around an attacker having your private key - which if they have would cause other major issues anyways. Not exactly newsworthy.
      • by Anonymous Coward

        Except that folks who don't know better are checking these files into their public repository and handing the attacker the private key.

      • That is one, and probably the most common, attack vector. There are other ways to introduce attack vectors as well, documented under the "Other exploitable scenarios" section. Even if you believe you are not vulnerable you should upgrade.

  • How can this be? Ruby on Rails is all magical goodness, right?
  • This exploit arises directly from clever code that hooks function names that don't even exist in the text of the codebase. So instead of find([:id]), you type find_by_id(). If I understand it correctly, the method-not-found exception handler pulls out the symbol from the function name itself and calls find(). This is the kind of crap that Ruby developers think is cool and useful.

    In Ruby, you are never coding by contract - you are coding by duck tape. It's an awesome language for throwing together a prototyp

  • If they have just released a fixed version than how can it be said that ALL versions are vulnerable? Really this sensationalism over fact gets irritating.
    • If they have just released a fixed version than how can it be said that ALL versions are vulnerable?

      ALL versions prior to the just-released fix are vulnerable, which means all versions actually in use when the announcement (simultaneous with the release of the fix) was made.

  • Real men write server-side cgis in assembly
  • by SuperKendall (25149) on Thursday January 03, 2013 @04:17PM (#42466115)

    Thanks to this vulnerability, I was able to edit every Web2.0 website and change the color scheme from gray-on-gray to something readable. And I reduced the font size 10-20 points.

    You can thank me later.

  • I tried running the exploit but activerecord chewed up all the system memory and the oomkiller took the server down. Luckily my server restart cron script runs every minute so my social media aggregator startup, disruptr.com, is back online.

Work is the crab grass in the lawn of life. -- Schulz

Working...