I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention.
The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just led to the current hysteria instead. They would have been better off being taking the extra time to be fully transparent about the nature of the vulnerability -- developers need to know to assess their own risk, as well as to judge the quality of Rails (how stupid was the problem exactly, what does it say about Rails etc?), etc. By being vague about it, Rails core team has just led to everyone assuming the worst, and the current weird hysteria.
Yes, it's a vulnerability which COULD be dangerous, and it's hard to tell FOR SURE if your app is vulnerable (perhaps due to code in gem dependencies), the only safe thing to do is update to a patched version. But the chances that your app is vulnerable are pretty small (if you aren't using AuthLogic; if you are, you can update auth_logic and fix it whether or not you update rails). And past recent vulnerabilities which were actually MORE dangerous have not received this level of attention.
This is a comment written under the confident assumption that the Phusion article is correct. I think the article is wrong, and wrong in a way that more or less invalidates this whole comment.
You should take this bug very seriously, and also pay close attention to Rails security releases for the next couple of weeks.
> I have no idea why THIS vulnerability is getting so much attention
Its getting attention because its the third SQL vulnerability in 7 months. It just feels like Rails is mature enough at this point that it shouldn't have to be going through this now
It's not an "SQL injection" vulnerability; it's a logic error that happens to impact the database rather than, say, OS command execution or file handling or the object space. If you're trying to get a handle on what the actual security issues and trends are with Rails, the "SQL" in the title of this vulnerability is very misleading.
I don't see how after a project matures, there should be no exploitable bugs? Even Java still has serious bugs on a yearly basis... The only secure systems are the ones nobody uses.
ActiveRecord was basically rewritten in Rails 3 due to the introduction of ActiveRelation. That could have introduced security issues that weren't there before.
That's potentially legit (people could argue about whether these rails vulnerabilities represent something to worry about in Rails, or whether even mature robust projects will still have bugs, including security bugs).
But the fact remains that THIS vulnerability isn't NEARLY as dangerous as some of those OTHER ones you mention in the last 7 months, but those other ones people mostly ignored, and THIS one they're going crazy thinking they need to fix right away.
What I think about the general question? Most (all?) of those Rails SQL injection bugs actually are related to a similar underlying design: Attempt to create methods with 'variable signatures', where you can give it a string OR a hash, or a list of various strings and hashes, and all of those things mean different things.
I think all of the Rails SQL injection bugs are actually related to variable arguments like that. When those variable argument methods were designed in Rails, it's probably safe to say nobody realized there were security implications, that it opens you up to a whole class of bugs where someone puts a hash where you expect a string and it change the semantics of the method call because your variable argument interpreting logic had some flaws. In retrospect, it's possibly not a great thing to do.
But Rails is not the only offender here, it's a pretty common design pattern in lots of ruby -- I think it's probably a mistaken one, but it is one that developers tend to like the convenience of.
I wish you'd stop telling people how dangerous you're sure this vulnerability is. I think you're probably wrong, but, more importantly, I think the only reason you're saying it is that you're echoing a meme started in an article by someone who isn't really involved in the research behind the vulnerability.
And of course, the truth of what you are saying is now evident with the vulnerabilty that 3.2.11 fixes.
What I still think this shows is that trying to keep information on the nature of the vulnerability to yourself is not a great idea. People who figured "Well, there's no way for params[:id] to be a hash with a symbol key" (such as myself) were wrong about the severity of the vulnerability.
It would have increased everyone's security to admit "Oh yeah, there might be a way to make params[:id] be a hash with symbol key even though you don't think so, yes you should worry about it."
Why not do that? Becuase you're worried you're giving someone exploitation hints, probably. But anyone that wanted to exploit had all the hints they need anyway -- as evidenced by the half dozen people credited with reporting the new vulnerability, all of whom got the hint from the 3.2.10 announcement anyway.
I have no idea why THIS vulnerability is getting so much attention. There have actually been OTHER Raisl vulnerabilities in the past 6-8 months which were _more dangerous_, but did not really get attention.
The Rails team did NOT help by being very vague about the nature of the problem in their announcement. I imagine they were trying to not reveal the method of exploitation; but it has just led to the current hysteria instead. They would have been better off being taking the extra time to be fully transparent about the nature of the vulnerability -- developers need to know to assess their own risk, as well as to judge the quality of Rails (how stupid was the problem exactly, what does it say about Rails etc?), etc. By being vague about it, Rails core team has just led to everyone assuming the worst, and the current weird hysteria.
Yes, it's a vulnerability which COULD be dangerous, and it's hard to tell FOR SURE if your app is vulnerable (perhaps due to code in gem dependencies), the only safe thing to do is update to a patched version. But the chances that your app is vulnerable are pretty small (if you aren't using AuthLogic; if you are, you can update auth_logic and fix it whether or not you update rails). And past recent vulnerabilities which were actually MORE dangerous have not received this level of attention.