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?).
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.
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:
You could make `params[:password_token]` return `{ "$ne" => "1" }` and effectively get any record from the database in MongoDB ORMs. So we limit the set of input values you can pass as argument for a while now. This is also why our patches were so simply, the whole sanitization infra structure was already there.
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.
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.
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.
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.
> 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).
