Ruby On Rails SQL Injection Flaw Has Serious Real-Life Consequences 117
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.
LOL (Score:1, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
To the GP, in terms of Entity Framework, or any other ORM in modern web applications, you need to be diligent in what you transmit over the wire as any other system. I will usually create
Re: (Score:1)
The suggestion of the GP to work around the issues of one framework's security by using an even more closed framework is naive at best. I like the .NET stack, even more with ASP.Net MVC, LINQ etc. But it isn't the end-all, be-all by a long shot. Every language/platform I've used has me longing at times for something else that does X, Y or Z easier/better.
I overlooked this comment. Anyway, I did not suggest that EF was some end-all-be-all solution to security, because it is certainly not that. But if you're developing with ASP.NET, it's a safe bet that Microsoft's flagship ORM is going to play nicely with it, very nicely. LINQ-to-Entities with SQL offers a extremely pleasant experience, with the declarative style closely mirroring that of the SQL the queries are compiled into. This leads to cleaner, more concise code as opposed to other ORMs like Hibernate/N
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Using a strongly typed language with a strongly typed database API, instead of that ugly hack called SQL will also mitigate SQL injections. Completely.
Re: (Score:1)
Re: (Score:2)
I don't think you got my point. I'm suggesting that SQL is contributing to the problem. Queries in is strings is not strongly typed. Function calls to BDB are. If you need an ORM to construct string queries, then you are trusting both yourself and the writers of the ORM framework writers to not screw up.
It safest to trust the fewest people not to screw up and then not screw up yourself.
Re: (Score:1)
Re: (Score:2)
>You don't understand software security, do you
Actually I do. It's my job. Well mostly hardware security, but they overlap.
SQL injections are a problem of untrusted data being mistaken for trusted code. When data cannot be mistaken for code it makes it very difficult for traditional SQL injection to happen. SQL promotes the problems of data/code confusion because it is a text string that contains both and constructing and handling that string correctly has provided lots of scope for error.
Keeping your da
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
"... 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.
Overraction (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.
Re: (Score:1)
Re: (Score:1)
Maybe they have a very old version and too much customization and they couldn't just apply a patch just like that. Assuming that everybody updates the OSS stuff religiously is naive. They generally have no clue that they have to do this on an ONGOING basis.
Re: (Score:2)
No, the attack isn't as bad as advertised, you have to know the "secret" key used for the cookie data, even after this bug. This bug makes it so that if you use a known "secret" key for the session data, for example the default key from an open source package, then the session cookie can be used for a SQL injection exploit. All the major rails-based blog and ecommerce packages generate the key when you're installing. It is a standard step. And when you have a custom app, it is always generated and there is
Re: (Score:1)
you have to know the "secret" key used for the cookie data
That was last week. This time there are no conditions.
Re: (Score:2)
Yeah, I have to revise my statement, I didn't know about the second wave this week, and we are busy patching dozens of applications. All rails apps are vulnerable until updated. This is pretty darn serious in the rails community.
Re:Overraction (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 [github.com]
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.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
The best answer to this would be to not use a system that is known to not be secure to begin with. That's a massive failure on the developer's part.
QED
Re: (Score:1)
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.
The best answer to this would be to not use a system that is known to not be secure to begin with. That's a massive failure on the developer's part.
QED
Perhaps, except for the fact that building your security out of what essentially is the equivalent of a rail fence to keep out a flood is doomed to fail. (See what I did there?) There are tools that can work for your stated purpose, and there are tools that are wholly unsuited to the intended application. RoR falls into the latter camp. Oh, and then there's the fact that I didn't talk about about technology xyz, but the actual one selected, and limited my comments to facts regarding said technology. Most ot
Re: (Score:3)
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/ [slashdot.org]
Re: (Score:3)
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.
Re: (Score:1)
Re: (Score:2)
Use an As400. Write your app in COBOL ... That ought to limit your hacker base to 40-70 year old males.
Re:Overraction (Score:5, Interesting)
Re: (Score:1)
Quagmire: "Really? The Dutch government does a decent job at being serious
Re:Overraction (Score:4, Insightful)
A vulnerability in a blog is not quite the same thing as a vulnerability in a system used to submit tax returns.
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
Re: (Score:1)
Why would anyone with a superior intellect develop for a piece of shit pile of security holes like Wordpress?
Your turn, nigger.
Why massa you don't have to develop for shit you don't like, you jus' have to tell us po' boys where the current security holes are. That's all. 2 minutes of your precious time, massa, is all we'uns ask. Your turn butthole.
Re: (Score:2)
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.
And a lot of governmental operations rely on Wordpress, do they?
Re:Overraction (Score:5, 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.
Re: (Score:2)
Re: (Score:2)
Silly???
It's exactly what they should do. Rather than crossing their fingers and leaving it open and exploitable they've shut it down until they fix it. Sure that inconveniences the users and makes IT look bad, but it's the only correct choice.
So? (Score:2, Funny)
This is a different vulnerability (Score:5, Informative)
Ruby in Holland (Score:1)
You can't even say :dyke anymore, it's women_in_comfortable_shoes()
Real-Life Consequences?! (Score:2)
I've been saying it for years. (Score:5, Interesting)
Re: (Score:2)
Re:I've been saying it for years. (Score:5, Informative)
Re: (Score:1)
Re: (Score:3, Informative)
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 => O
Re: (Score:2)
Hint to brogrammers: /dev/random
Which will either block or give you data with no entropy unless you really know what you're doing.
Re: (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 [google.com]. Please try to keep up.
Re: (Score:2)
But this is just as hard to invoke, because it requires the application to take a string from an untrusted source, parse it as YAML or XML, and then use the resulting Hash as an argument -- this would only happen if you were taking some sort of web service request or submitted file, parsing it without validation, and then passing it verbatim to the ActiveRecord finder methods.
Parsing untrusted information and then passing it to the API without any validation is a fail. This is a nominal exploit, but you n
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
I think your position is a reasonable one.
However, it's not particularly relevant to the security hole. The bug has to do with deserialization of parameters rather than SQL specifically; the SQL injection exploit is but one possible exploit of the bug.
Moreover it's not inconceivable (likely, in fact) that other bugs of the same class exist in projects other than rails. Avoiding Rails altogether doesn't protect you from this class of bug.
Re: (Score:1)
Totally agree with you. I was a long time Java, PHP developer and learned Rails to take over a project from a big firm in Atlanta. The level of BS these guys spew is insane. They chose Postgres as the database simply because its what Heroku says to do. I love Postgres, but if you are a major shop doing an application rewrite and not one person can articulate a reason for why you chose the backbone tech for the site...that is not good.
They cared more about the code being "beautiful" than making sure it w
Re: (Score:1)
As stated, I love Postgres and there's many reasons to select it as a database. Nobody in charge of selecting it knew any of those reasons, which was shocking.
It is a solid solution for this, but the level of inefficiency in the code this particular crew was putting out was appalling.
Just a couple of "off the top of my head examples:
There was a user dashboard system that showed users a list of buying, bought, sold, selling, and expired listings. Rather figure out what constituted any of these relationship
Re: (Score:2)
What would you use instead of Postgres?
Re: (Score:2)
Ok, I'd say that I wanted a cheap, reliable database, and I didn't want MySQL. The person being asked couldn't say that?
Re: (Score:1)
There's nothing wrong with Ruby. I love Ruby. For production deployments I'm also finding that jRuby fixes the bulk of Ruby's issues under load.
The problem is the dependency on Active Record without the slightest understanding of how the database behind it works, focussing on writing all of your code in ruby and not take the slightest advantage in letting your database do what it's specifically BUILT to do. If you wanted to say, get 20,000 of 500,000 records from a database in a certain order would you p
Re: (Score:3)
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".
Re: (Score:2)
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.
To know and understand SQL is to know and understand that it is a steaming pile and other interfaces should be used.
Re:WHAT THE FUCK IS WRONG WITH THE MODERN WORLD? (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.
Re: (Score:2)
seeeeeeeeeebs! Wish I had a mod point for you. :)
Re: (Score:2)
oh, because expensive proprietary frameworks (eg websphere or weblogic) or other open source ones (zend) never have such vulnerabilities?
you're ignorant
Ruby on Fails (Score:2)
Not obvious what is actually at issue. (Score:2)
Down for upgrades? Down for an evaluation of whether upgrades are needed? Down for code fixes? Down because they need to evaluate what happened after confirming attack happened?
The actual vulnerability was not automatically present; it's easy to use Rails and not have this vulnerability affect you, because while the vulnerability is nominally in the code base, there's no paths to trigger it without specific code -- so either you'd have to use a specific third-party library, or write your own code which does
Re: (Score:1)
so either you'd have to use a specific third-party library, or write your own code which does the same things. So it might well be that the site is not actually vulnerable
This is /. writing code is no discouragement to anyone here. If all you had to do to steal all social security information for an entire country was 'write your own code', there will be takers.
Toy (Score:2, Insightful)
Re: (Score:1)
"Fixes were released, so it looks like it's on (Score:2)
their sysadmin team now."
I laughed
1- Maybe implementing, validating, testing... the fix does take a bit of time ?
2- This sounds so much like a teenager "But Daddy, I know last time I went out I got back past curfew drunk and smelling of cigarettes... but that was LAST TIME, I'm trustworthy now... what's the hold-up ?"
Exaggerated (Score:2)
This means that 16 million Dutch citizens cannot authenticate themselves anymore with government instances ON LINE, and that those same government instances can not DIGITALLY communicate anything to those same citizens anymore.
So instead, you make a phone call?
Re: (Score:1)
This system is for example used for authenticating our tax-submission. It's quite vital for a lot of communication between goverment and civilians, since there are no (easy) other ways to perform such by law enforced civil tasks.
ps: a month a ago there were problems with the phone and it wasnt even possible to dail 911 (112)
Let's not overreact (Score:1)
Re: (Score:1)