5 ms·

Security Announcement for Devise (Rails authentication solution)

66 points by Argorak 14y ago

CaveTech 14y ago
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.
- jpdoctor 14y ago
  > 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)
  - yxhuvud 14y ago
    Except for the fact that there are plenty of installations in enterprisey environments that don't get updated regularly enough.
    - possiblemat 14y ago
      Just like with any technology stack.
  - daeken 14y ago
    > 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).
- hemancuso 14y ago
  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.
- tptacek 14y ago
  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.
  - joernchen 14y ago
    This very much is true. I'll put some details up soon.
  - slowpoison 14y ago
    Can you please link to the remote execution bug?
    - tedunangst 14y ago
      http://news.ycombinator.com/item?id=5028218 http://news.ycombinator.com/item?id=5028218
  - benmmurphy 14y ago
    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.
lucian1900 14y ago
Is "all other databases" a euphemism for MySQL?
- epochwolf 14y ago
  Yes.
- josevalim 14y ago
  No. SQL Server, Oracle, IBM and other NoSQL databases. Everything that runs on Rails that is not SQLite3 or PostgreSQL requires an upgrade.
  - michaelbuckbee 14y ago
    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.
    - josevalim 14y ago
      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: User.where(password_token: params[:password_token]) 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.
  - tptacek 14y ago
    What NoSQL database is vulnerable to this flaw?
cschneid 14y ago
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?).
- josevalim 14y ago
  "Upgrade immediately" so do drop everything. I have amended the blog post to mention an attacker could gain control of other accounts.
  - cschneid 14y ago
    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.

66 points by Argorak 14y ago

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.

jpdoctor 14y ago
> 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)
- yxhuvud 14y ago
  Except for the fact that there are plenty of installations in enterprisey environments that don't get updated regularly enough.
  - possiblemat 14y ago
    Just like with any technology stack.
- daeken 14y ago
  > 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).
hemancuso 14y ago
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.
tptacek 14y ago
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.
- joernchen 14y ago
  This very much is true. I'll put some details up soon.
- slowpoison 14y ago
  Can you please link to the remote execution bug?
  - tedunangst 14y ago
    http://news.ycombinator.com/item?id=5028218 http://news.ycombinator.com/item?id=5028218
- benmmurphy 14y ago
  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.

lucian1900 14y ago

Is "all other databases" a euphemism for MySQL?

epochwolf 14y ago
Yes.
josevalim 14y ago
No. SQL Server, Oracle, IBM and other NoSQL databases. Everything that runs on Rails that is not SQLite3 or PostgreSQL requires an upgrade.
- michaelbuckbee 14y ago
  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.
  - josevalim 14y ago
    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: User.where(password_token: params[:password_token]) 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.
- tptacek 14y ago
  What NoSQL database is vulnerable to this flaw?

cschneid 14y ago

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?).

josevalim 14y ago
"Upgrade immediately" so do drop everything. I have amended the blog post to mention an attacker could gain control of other accounts.
- cschneid 14y ago
  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.