Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ruby On Rails SQL Injection Flaw Has Serious Real-Life Consequences

Posted by Unknown on from the should-have-used-cobol dept.

vikingpower writes "As a previous Slashdot story already reported, Ruby on Rails was recently reported to suffer from a major SQL injection flaw. This has prompted the Dutch government to take the one and only national site for citizens' digital identification offline (link in Dutch, Google translation to English). Here is the English-language placeholder page for the now-offline site. This means that 16 million Dutch citizens cannot authenticate themselves anymore with government instances, and that those same government instances can not communicate anything to those same citizens anymore." Fixes were released, so it looks like it's on their sysadmin team now.

17 of 117 comments (clear)

  1. Overraction by mortonda · · Score: 2, Insightful

    That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.

    1. Re:Overraction by Serious+Callers+Only · · Score: 5, Interesting

      This one is quite a serious flaw, and the data this website in question deals with is very important data (citizen IDs), so I'm not surprised they're taking it seriously. The service being down for a day or two is probably better than millions of ids getting hacked. Perhaps the fix breaks something on their website, and they have to fix that before they can take it back up again? It has produced issues like this I think:

      https://github.com/rails/rails/issues/8831

      Most sites (like Slashdot) really don't matter if they are hacked and could just stay up, but something dealing with identity like this deserves special attention, and I'm sure they have good reasons if they have taken the site down while they look at workarounds. Perhaps it'll mean they get more money devoted to securing the site after this has blown over - time spent testing the site and looking at security is probably more important than the specific technology used (almost every major framework has regular security problems like this), contrary to the righteous flaming and trolling for asp.net/perl/php/other tech which is bound to erupt in the wake of your post.

    2. Re:Overraction by slashdime · · Score: 5, Interesting

      Really? The Dutch government does a decent job at being serious on maintaining security of their citizens' identification data and your first thought is to criticize them for overreacting? You've obviously never worked with sensitive data. Any decent admin's reaction should have been the same if it included the possible leak of sensitive data. This is an entire country's data. You have no idea what you're talking about and should just shut your pie hole.

    3. Re:Overraction by mcvos · · Score: 3, Insightful

      A vulnerability in a blog is not quite the same thing as a vulnerability in a system used to submit tax returns.

    4. Re:Overraction by LordThyGod · · Score: 2

      Wrong (again!). What you meant to say was *WordPress plugins*, that are mostly abandoned open source projects. Your active support, participation, and superior intellect would surely be welcomed.

    5. Re:Overraction by benjymouse · · Score: 4, Insightful

      That's just silly, since the fix can be easily applied. It really nothing compared to all the wordpress exploits out the that never get patched.

      Really?

      This is a system that controls access to virtually all of the government public sites. It deals with extremely sensitive data and I guarantee you that no single administrator is allowed to download a patch and just apply it.

      It is not a hobbyist blogging site, it is a vital piece of a country infrastructure.

      Any change will have to be reviewed, tested and verified, with full sign off, logging, documentation and procedural oversight. The SOP when integrity cannot be guaranteed *should* be to shut down until reliable assessment can be made.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    6. Re:Overraction by Charliemopps · · Score: 2

      No, the best answer is not number every citizen and have those numbers be so important that it could do so much damage. No system could ever be secure enough for what the Dutch are doing. This doesn't even get into the privacy concerns and the havoc that could happen should the wrong people get into office.

    7. Re:Overraction by Serious+Callers+Only · · Score: 2

      Most other technologies don't have this flaw as a core feature, you have to code it that way. So you might want to revisit your "QED".

      Most other technologies do have exactly this kind of exploit (I think this is more serious than the article states, it's a remote execution flaw, not SQL injection as you seem to assume from reading the summary), and many have and will continue to suffer from SQL injection flaws as they find their safeguards weren't quite what they thought they were. Here's a hole in the Java from the day after (note that I don't think that makes Java immediately unsuitable for any use):

      http://developers.slashdot.org/story/13/01/10/1540202/java-zero-day-vulnerability-rolled-into-exploit-packs

      Security is a process, i.e. you have to keep continually on top of it and react quickly to disclosures. It's not something you can just assume because you chose 'secure' technology, or audit once and forget about, and it's not something which any particular technology has a monopoly on. It's quite possible to build secure sites with rails if you know what you're doing, do your own parameter checking on top of what rails provides, and keep on top of security updates. Perfect security probably isn't attainable with any language, but I'm sure you weren't implying that it was. Curious that you seem to think Rails is particularly insecure though, have you ever used it?

      Which tool in particular did you feel would work for this purpose? All the major languages or frameworks I can think of have had serious security problems in the past, none are a priori secure.

  2. This is a different vulnerability by bimozx · · Score: 5, Informative

    This is a different security vulnerability that was brought to light a few days ago, which was given the full detail in this article. Finder method SQL Injection vulnerability Any Rails version that was build for the last 6 years is affected by this. This is a serious security flaw, it is sternly advised that you update your application immediately if your Rails version is in the bucket. You can refer to this discussion for more details.

  3. I've been saying it for years. by multicoregeneral · · Score: 5, Interesting

    And this, children, is why you actually need to know and understand SQL before you go off and start writing database applications, without depending on a "framework" to do it for you.

    --
    This signature intentionally left blank.
    1. Re:I've been saying it for years. by dam.capsule.org · · Score: 5, Informative

      It's a bit more complicated than a simple sql injection: see http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-your-horses-here-are-the-facts/

      --
      What sig ?
    2. Re:I've been saying it for years. by iluvcapra · · Score: 2, Informative

      You got marked as flamebait, but I have to agree. I find it amazing that this is even possible in something like RAILs which is supposed to abstract away all the SQL for you.

      Note, all parameters from the user's POST or GET are sanitized when passed to the finder methods, but developer-only parameters to the methods in question are exploited by the attacker sticking data into the server's Session object for the request, or by fooling the server into decoding a submitted parameter as a Hash of Symbol => Object pairs, instead of a String objects. This vector that's been described doesn't work unless the attacker has the HMAC that's signing the session cookie.

      The object method in question accepts either a string or a Hash of Symbol => Object pairs, and in the second case allows specifying arbitrary SQL clauses -- these are available for efficiency reasons and the documentation's pretty clear that these aren't sanitized, because they can't be. The problem for the attacker is somehow getting a user-created Hash, with Symbol keys, into the application, which is impossible through GET or POST parameters; the only way people have managed to do it is through forging a Session, which requires having the application's session shared secret.

      --
      Don't blame me, I voted for Baltar.
    3. Re:I've been saying it for years. by shutdown+-p+now · · Score: 2

      There's nothing wrong with using a framework that does normal escaping (or, better yet, just uses parametrized queries consistently). The problem in this case is that Rails is too magical for its own good. So I would amend that to "don't use magical frameworks that claim to do everything without you doing nothing".

    4. Re:I've been saying it for years. by coma_bug · · Score: 3, Insightful

      This vector that's been described doesn't work unless the attacker has the HMAC that's signing the session cookie.

      That was last week. This time attackers can bypass authentication systems, inject arbitrary SQL, inject and execute arbitrary code, or perform a DoS attack. Please try to keep up.

  4. Re:WHAT THE FUCK IS WRONG WITH THE MODERN WORLD? by seebs · · Score: 5, Insightful

    You know, it's pretty obvious that you're trolling, but there's a real question here:

    Why would we use frameworks, given that they have security bugs coming up all the time?

    Answer: Because code people write themselves isn't any less buggy, and with a framework, at least you have other people looking for bugs too.

    --
    My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
  5. Re:LOL by AlphaBro · · Score: 2

    Laugh it up buddy, but LINQ to Entities largely eliminates SQL injection in ASP.NET web applications.

  6. Re:LOL by Jane+Q.+Public · · Score: 2

    "... compared to a SQL Injection you can't do much about."

    Quite the contrary; it is ridiculously easy to prevent this SQL injection attack. All you have to do is change the default "secret" key value, which should always be done in a Rails program.

    Every competent Rails programmer knows about the "secret" value, and that it should be changed from the default. They documentation clearly says so, and the file containing it says "Change this!". Failing to do so is akin to not changing the default password on your WiFi router... anybody can get in if they know how. (AND, in this case, if you happen to be using Authologic.)

    This is a "flaw" that normally affects only programs written by Ruby noobs. (Newby rubes...)