Security Announcement for Devise (Rails authentication solution)(blog.plataformatec.com.br)
blog.plataformatec.com.br
Security Announcement for Devise (Rails authentication solution)
http://blog.plataformatec.com.br/2013/01/security-announcement-devise-v2-2-3-v2-1-3-v2-0-5-and-v1-5-3-released/
3 comments
Is there any more info about the severity of this attack? Is this a drop-everything issue? What are the vulnerable endpoints (reading between the lines implies password resets?).
"Upgrade immediately" so do drop everything. I have amended the blog post to mention an attacker could gain control of other accounts.
Thanks. Is there a firewall level rule we can use to block requests (in addition to updating rails itself). We have a ton of apps to update, so a catchall rule would be very helpful.
Is "all other databases" a euphemism for MySQL?
No. SQL Server, Oracle, IBM and other NoSQL databases. Everything that runs on Rails that is not SQLite3 or PostgreSQL requires an upgrade.
That's really interesting/terrifying - I wouldn't have suspected NoSQL datastores to be susceptible. Now I'm really interested in seeing what the root cause was.
Unfortunately, the problem is not only the NoSQL data stores but their ORMs. In fact, Devise was not vulnerable to any of the Rails previous vulnerabilities because MongoDB ORMs forced us a long time ago to sanitize all input values because if you do this:
We were not able to test all ORMs and databases (because we would need to effectively test combinations of those) but we could verify the problem does not happen for PostgreSQL nor SQLite3. That's why you must upgrade if you don't want to take any risks.
User.where(password_token: params[:password_token])
We were not able to test all ORMs and databases (because we would need to effectively test combinations of those) but we could verify the problem does not happen for PostgreSQL nor SQLite3. That's why you must upgrade if you don't want to take any risks.
What NoSQL database is vulnerable to this flaw?
Yes.
Ruby is really plagued by security concerns at the moment, even though most of them seem to be stemming from the same issues. Just makes me wonder how many blackhats figured these out years ago and have been abusing them under everyones noses.
This issue has nothing to do with either the "SQL injection" bug from a few weeks back (which wasn't SQL injection so much as a very limited form of code injection) or the remote code execution bug. It's (I believe) a MySQL type coercion bug.
If this is the bug I think it is (from following joernchen), it has a lot more to do with the "MySQL is terrible" post from a few days back than it does with Rails/Devise.
The recent remote code execution bug was so bad that I think it is in fact legit to worry about how many people had been running around with it months or years before disclosure.
If this is the bug I think it is (from following joernchen), it has a lot more to do with the "MySQL is terrible" post from a few days back than it does with Rails/Devise.
The recent remote code execution bug was so bad that I think it is in fact legit to worry about how many people had been running around with it months or years before disclosure.
This bug looks similar to the previous rails SQL injection/manipulation issues. The code expects some type T but instead gets a type U and because of this some unexpected behaviour happens. In a typesafe language this mistake would be harder to make. This is a really ugly one to solve and there is going to be lots of rails code bases that are going to be vulnerable to this issue. Maybe there is an option in mysql or the vulnerable databases to treat this as an error rather than generate a warning.
if you don't have anything that is enforcing types then you are fucked :) it is ok to have untyped (or weakly typed) db and statically typed frontend. it is ok to have typed db and dynamically typed frontend. but if you have untyped db and dynamically typed frontend you are in for a world of pain.
if you don't have anything that is enforcing types then you are fucked :) it is ok to have untyped (or weakly typed) db and statically typed frontend. it is ok to have typed db and dynamically typed frontend. but if you have untyped db and dynamically typed frontend you are in for a world of pain.
This very much is true. I'll put some details up soon.
Can you please link to the remote execution bug?
The only meaningful take-away from these concerns is you shouldn't ever let a rails project you maintain ossify to the extent that you can't easily/safely run "bundle update", commit, and deploy.
> Just makes me wonder how many blackhats figured these out years ago
I had a different guess: Rails has gotten so popular that it's worth investing time as a blackhat because there will be payoff.
Of course, if the rails community responds quite rapidly, the return-on-effort for the black hats drops substantially. (hint hint)
I had a different guess: Rails has gotten so popular that it's worth investing time as a blackhat because there will be payoff.
Of course, if the rails community responds quite rapidly, the return-on-effort for the black hats drops substantially. (hint hint)
> Of course, if the rails community responds quite rapidly, the return-on-effort for the black hats drops substantially. (hint hint)
Well, not quite. In security there's a fundamental imbalance between attackers and defenders: a defender needs to find every bug, where an attacker only needs to find one. At the end of the day, if it's a platform that's worth attacking, attackers will always have the upper hand. This is why finding and fixing individual bugs is not nearly as effective as eliminating whole classes of bugs; of course, it's much cheaper to do.
Rails has been pretty good on the whole, in terms of security. Given the size and wide distribution of the platform, it's held up impressively well. Of course, the last couple bugs have marred that a bit, and there are definitely places where Rails apps have traditionally failed badly (e.g. mass assignment).
Well, not quite. In security there's a fundamental imbalance between attackers and defenders: a defender needs to find every bug, where an attacker only needs to find one. At the end of the day, if it's a platform that's worth attacking, attackers will always have the upper hand. This is why finding and fixing individual bugs is not nearly as effective as eliminating whole classes of bugs; of course, it's much cheaper to do.
Rails has been pretty good on the whole, in terms of security. Given the size and wide distribution of the platform, it's held up impressively well. Of course, the last couple bugs have marred that a bit, and there are definitely places where Rails apps have traditionally failed badly (e.g. mass assignment).
Except for the fact that there are plenty of installations in enterprisey environments that don't get updated regularly enough.
Just like with any technology stack.