5 ms·

Rack - Important Security Upgrade

56 points by dpaluy 14y ago

static_typed 14y ago
Another day, another Ruby security bump. Sigh. Serious point - as Ruby seems to attract all the younger generation of programmers these days, and the current trend seems to be dev early, release early, security hole early, could this be turned around by more experienced hands joining the community? Could the Ruby way become a bit safer and more secure in time?
- jabo 14y ago
  You mean Rails and not Ruby.
  - callahad 14y ago
    Rack is not Rails.
  - jrochkind1 14y ago
    I think he means ruby. I'd agree that, in the ruby community in general, or at least the English-speaking ruby community, general cultural values seem to be "dev early, release early, security hole early". Valuing innovation and release-often over stability/reliability. There are certainly some projects/developers that go against this cultural norm, but we are certainly not the first to recognize it as a general cultural norm in rubydom (and it's got benefits as well as disadvantages).
    - static_typed 14y ago
      Yes, given we have seen issues in Core Ruby libraries (only recently updating the CSV lib), in Rails, in Ruby Gems, in Rack, it seems to pervade the Ruby Community. Secure is not cool, nor magic enough, it seems.
      - nfm 14y ago
        I'm going against my better judgement in trying to critically engage you, but what's your background? Are you a security researcher? Have you audited Django? Have you read the Python source code? Why do you think a given language community is going to be more secure than another? Is security one of the tenets of Python?
- zpe 14y ago
  Sigh, another day, another post from you bashing the "ruby community". You got you message accross - ruby sucks, you're migrating to php, good for you! I've read like 15 post from you saying the exact same thing. Please, enough already!
- bradleyland 14y ago
  You know, I'm grateful for all the CVE's lately. Every CVE means another attack vector that the good guys found, and I'm now protected against. Evaluating the security of a framework is difficult, because not all frameworks receive the same level of scrutiny. I'm considering this Ruby's "Microsoft moment". We're at a period of time where a lot of people are scrutinizing popular Ruby projects like Rails and Rack. I'm hoping that the outcome of this will be: * Many security vulnerabilities are found and patched * More Ruby developers will consider security first, because that's what's in the news Maybe I'm just a little pollyanna in the brain, but there's good work being done in Ruby right now.
Robin_Message 14y ago
How bad is this? I assume they say that Rails-based sessions are secure as they are HMAC'd with a secret, which a timing attack won't break unless the Rails HMAC testing is broken.
- jrochkind1 14y ago
  It is confusing. Because of course rack is used by more than just rails, the rack team's responsibility isn't reallyto say "If you're using Rails with it's default signature verification, you're not vulnerable" -- they don't even have the background to be sure that's true (even rails team might not, security is hard). The announcement also implies that the timing vulnerability _might_ only be exposed to people on the same local network who have sufficient timing granularity -- BUT that this applies to anything in the cloud, since people on the same cloud are essentially in same local network. So if you're not in the cloud... On the other hand, I've [fucked up before](http://news.ycombinator.com/item?id=5003132 http://news.ycombinator.com/item?id=5003132) _thinking_ I understood the vulnerability and that it was unlikely to effect me, when in fact I was operating without full information and misunderstanding the true extent of the vulnerability. So now I figure, if the maintainers say "Todays releases are important. All users should upgrade ASAP!", I better just act as if they are right. Even though sometimes they won't be and are being over alarmist, I'm not qualified to know when.
wildchild 14y ago
2.5 years old issue https://twitter.com/coda/status/299732877745197056 https://twitter.com/coda/status/299732877745197056 Impressive.
ufo 14y ago
I searched a bit and found patches that I think help to explain what was going on and how severe things worse. I'd appreciate if anyone could confirm I found the correct stuff and if anyone could help explain what happened (in particular, I don't understand why the timing attack bug would lead to a remote code execution) ----------- The first bug seems to be in some function that checks if you can find a file in a folder. Currently the funtion counts the number of ".."s to make sure you don't go out of the folder you started the search in (emitting an error if the depth becomes less than 0) however, this does not take into account the possibility of one of the intermediate folders in the pathbeing a symlink, meaning that the `./symlink/../bar` is not the same as `./bar` and therefore ruining the logic. The fix seems to be a hack to transform `./xxx/../b`s into `./b` by hand, without passing it to the fylesystem. https://github.com/rack/rack/commit/6f237e4c9fab649d3750482514f0fde76c56ab30 https://github.com/rack/rack/commit/6f237e4c9fab649d37504825... The second bug seems to have to do with `==` not being safe and them having to do a "secure compare": https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07 https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6... edit: apparently the problem here is the time that `==` takes to run depends on the inputs. This means an attacker can do multiple carefully crafted requests and use this timing information to guess your secret key stuff. I still don't know why guessing the secret stuff would lead to remote code execution though.
- chrismcbride 14y ago
  The second one is a timing issue. You need to have an equality method that takes an equal amount of time on success or failure. Heres a good read on timing attacks in general: http://codahale.com/a-lesson-in-timing-attacks/ http://codahale.com/a-lesson-in-timing-attacks/
  - vinhboy 14y ago
    "In short, a timing attack uses statistical analysis of how long it takes your application to do something in order to learn something about the data it’s operating on" -- great read.. my mind is blown for today...
- gravitronic 14y ago
ChuckMcM 14y ago
The RoR security issues have been depressing for me. My daughter had a credit card stolen from a web site, built on rails by a third party for the owner, the owner didn't know what powered the web site, they had a really "easy to use" tool for putting things up there. A code audit showed the site had been completely re-done to appear the same and provide a card harvesting service forwarding card information to the Ukraine. How many more of these are there out there? tens? hundreds? thousands?
- kawsper 14y ago
  Also, as I understand it, many american websites seems to store credit card details, why is that? In Denmark we often use a payment gateway, exactly to avoid these types of attack. If my webshops database got leaked, my customers would not have to fear creditcard leakage.
  - deleted 14y ago
    [deleted]
  - steveklabnik 14y ago
    Many American websites use payment gateways as well. That doesn't mean they all do. We have laws that you must comply with if you store data: http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...
    - datasage 14y ago
      Not a law, its an industry standard. Its enforced by the card companies (Visa, etc) but generally only if you are processing enough transactions.
      - steveklabnik 14y ago
        Ahh, I was mistaken. I thought that you could be hit with fines if you don't comply with PCI. (This is why I always use a payment gateway and never keep details myself.)
trustfundbaby 14y ago
I imagine there's going to have to be a Rails release to upgrade the Rack versions used?
- steveklabnik 14y ago
  Three things: 1. Some Rails apps shouldn't be affected, since Rails uses its own HMAC stuff to handle this. From the rack homepage: "Some Rails users may not be affected (if they only use Rails managed sessions)." 2. You don't need an upgrade of Rails, just `bundle update rack`. 3. 3-2-stable has already had the rack dependency bumped, so the next release of 3.2 will include a minium of this latest release.
rachelbythebay 14y ago
I never realized the rack logo used the same font that Rackspace used to use. It was a little disconcerting to see that at first. For those who remember, it's the one which had 8 little rectangular machines, with one of them pulled out a bit and glowing red. I used to say it was the one that was on fire, because, well, it happens!

56 points by dpaluy 14y ago

Another day, another Ruby security bump. Sigh. Serious point - as Ruby seems to attract all the younger generation of programmers these days, and the current trend seems to be dev early, release early, security hole early, could this be turned around by more experienced hands joining the community? Could the Ruby way become a bit safer and more secure in time?

jabo 14y ago
You mean Rails and not Ruby.
- callahad 14y ago
  Rack is not Rails.
- jrochkind1 14y ago
  I think he means ruby. I'd agree that, in the ruby community in general, or at least the English-speaking ruby community, general cultural values seem to be "dev early, release early, security hole early". Valuing innovation and release-often over stability/reliability. There are certainly some projects/developers that go against this cultural norm, but we are certainly not the first to recognize it as a general cultural norm in rubydom (and it's got benefits as well as disadvantages).
  - static_typed 14y ago
    Yes, given we have seen issues in Core Ruby libraries (only recently updating the CSV lib), in Rails, in Ruby Gems, in Rack, it seems to pervade the Ruby Community. Secure is not cool, nor magic enough, it seems.
    - nfm 14y ago
      I'm going against my better judgement in trying to critically engage you, but what's your background? Are you a security researcher? Have you audited Django? Have you read the Python source code? Why do you think a given language community is going to be more secure than another? Is security one of the tenets of Python?
zpe 14y ago
Sigh, another day, another post from you bashing the "ruby community". You got you message accross - ruby sucks, you're migrating to php, good for you! I've read like 15 post from you saying the exact same thing. Please, enough already!
bradleyland 14y ago
You know, I'm grateful for all the CVE's lately. Every CVE means another attack vector that the good guys found, and I'm now protected against. Evaluating the security of a framework is difficult, because not all frameworks receive the same level of scrutiny. I'm considering this Ruby's "Microsoft moment". We're at a period of time where a lot of people are scrutinizing popular Ruby projects like Rails and Rack. I'm hoping that the outcome of this will be: * Many security vulnerabilities are found and patched * More Ruby developers will consider security first, because that's what's in the news Maybe I'm just a little pollyanna in the brain, but there's good work being done in Ruby right now.

Robin_Message 14y ago

How bad is this? I assume they say that Rails-based sessions are secure as they are HMAC'd with a secret, which a timing attack won't break unless the Rails HMAC testing is broken.

jrochkind1 14y ago
It is confusing. Because of course rack is used by more than just rails, the rack team's responsibility isn't reallyto say "If you're using Rails with it's default signature verification, you're not vulnerable" -- they don't even have the background to be sure that's true (even rails team might not, security is hard). The announcement also implies that the timing vulnerability _might_ only be exposed to people on the same local network who have sufficient timing granularity -- BUT that this applies to anything in the cloud, since people on the same cloud are essentially in same local network. So if you're not in the cloud... On the other hand, I've [fucked up before](http://news.ycombinator.com/item?id=5003132 http://news.ycombinator.com/item?id=5003132) _thinking_ I understood the vulnerability and that it was unlikely to effect me, when in fact I was operating without full information and misunderstanding the true extent of the vulnerability. So now I figure, if the maintainers say "Todays releases are important. All users should upgrade ASAP!", I better just act as if they are right. Even though sometimes they won't be and are being over alarmist, I'm not qualified to know when.

wildchild 14y ago

2.5 years old issue https://twitter.com/coda/status/299732877745197056 https://twitter.com/coda/status/299732877745197056 Impressive.

ufo 14y ago

I searched a bit and found patches that I think help to explain what was going on and how severe things worse. I'd appreciate if anyone could confirm I found the correct stuff and if anyone could help explain what happened (in particular, I don't understand why the timing attack bug would lead to a remote code execution) ----------- The first bug seems to be in some function that checks if you can find a file in a folder. Currently the funtion counts the number of ".."s to make sure you don't go out of the folder you started the search in (emitting an error if the depth becomes less than 0) however, this does not take into account the possibility of one of the intermediate folders in the pathbeing a symlink, meaning that the `./symlink/../bar` is not the same as `./bar` and therefore ruining the logic. The fix seems to be a hack to transform `./xxx/../b`s into `./b` by hand, without passing it to the fylesystem. https://github.com/rack/rack/commit/6f237e4c9fab649d3750482514f0fde76c56ab30 https://github.com/rack/rack/commit/6f237e4c9fab649d37504825... The second bug seems to have to do with `==` not being safe and them having to do a "secure compare": https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d67dbac8b4863a7f07 https://github.com/rack/rack/commit/0cd7e9aa397f8ebb3b8481d6... edit: apparently the problem here is the time that `==` takes to run depends on the inputs. This means an attacker can do multiple carefully crafted requests and use this timing information to guess your secret key stuff. I still don't know why guessing the secret stuff would lead to remote code execution though.

chrismcbride 14y ago
The second one is a timing issue. You need to have an equality method that takes an equal amount of time on success or failure. Heres a good read on timing attacks in general: http://codahale.com/a-lesson-in-timing-attacks/ http://codahale.com/a-lesson-in-timing-attacks/
- vinhboy 14y ago
  "In short, a timing attack uses statistical analysis of how long it takes your application to do something in order to learn something about the data it’s operating on" -- great read.. my mind is blown for today...
gravitronic 14y ago

ChuckMcM 14y ago

The RoR security issues have been depressing for me. My daughter had a credit card stolen from a web site, built on rails by a third party for the owner, the owner didn't know what powered the web site, they had a really "easy to use" tool for putting things up there. A code audit showed the site had been completely re-done to appear the same and provide a card harvesting service forwarding card information to the Ukraine. How many more of these are there out there? tens? hundreds? thousands?

kawsper 14y ago
Also, as I understand it, many american websites seems to store credit card details, why is that? In Denmark we often use a payment gateway, exactly to avoid these types of attack. If my webshops database got leaked, my customers would not have to fear creditcard leakage.
- deleted 14y ago
  [deleted]
- steveklabnik 14y ago
  Many American websites use payment gateways as well. That doesn't mean they all do. We have laws that you must comply with if you store data: http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...
  - datasage 14y ago
    Not a law, its an industry standard. Its enforced by the card companies (Visa, etc) but generally only if you are processing enough transactions.
    - steveklabnik 14y ago
      Ahh, I was mistaken. I thought that you could be hit with fines if you don't comply with PCI. (This is why I always use a payment gateway and never keep details myself.)

trustfundbaby 14y ago

I imagine there's going to have to be a Rails release to upgrade the Rack versions used?

steveklabnik 14y ago
Three things: 1. Some Rails apps shouldn't be affected, since Rails uses its own HMAC stuff to handle this. From the rack homepage: "Some Rails users may not be affected (if they only use Rails managed sessions)." 2. You don't need an upgrade of Rails, just `bundle update rack`. 3. 3-2-stable has already had the rack dependency bumped, so the next release of 3.2 will include a minium of this latest release.

rachelbythebay 14y ago

I never realized the rack logo used the same font that Rackspace used to use. It was a little disconcerting to see that at first. For those who remember, it's the one which had 8 little rectangular machines, with one of them pulled out a bit and glowing red. I used to say it was the one that was on fire, because, well, it happens!