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

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.

This is a different vulnerability

[bimozx]

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 [phusion.nl] 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 [google.com] for more details.

Re:I've been saying it for years.

[dam.capsule.org]

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/ [phusion.nl]

Re:I've been saying it for years.

[iluvcapra]

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.