6 ms·

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 blac

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.

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.