Rack - Important Security Upgrade(rack.github.com)
rack.github.com
Rack - Important Security Upgrade
http://rack.github.com/
7 comments
I'm sorry to hear the problems you and your family had with it.
But on the discussion we had before[1], this one does not seem to affect Rails[2]:
tiegz 14 hours ago | link | parent
Rails has been built around Rack for a couple years, but I think its sessions are safe from this Rack vulnerability. Rails' CookieStore class inherits from Rack::Session::Cookie, but it overwrites the unpacked_cookie_data() method which was open to a timing attack. Rails uses its own MessageVerifier class (https://github.com/rails/rails/blob/master/activesupport/lib...) to do a constant time comparison, which would avoid this attack.
Any other frameworks/libs that use Rack's session cookies should upgrade though, afaik.
[1] http://news.ycombinator.com/item?id=5186245
[2] http://news.ycombinator.com/item?id=5186466
But on the discussion we had before[1], this one does not seem to affect Rails[2]:
tiegz 14 hours ago | link | parent
Rails has been built around Rack for a couple years, but I think its sessions are safe from this Rack vulnerability. Rails' CookieStore class inherits from Rack::Session::Cookie, but it overwrites the unpacked_cookie_data() method which was open to a timing attack. Rails uses its own MessageVerifier class (https://github.com/rails/rails/blob/master/activesupport/lib...) to do a constant time comparison, which would avoid this attack.
Any other frameworks/libs that use Rack's session cookies should upgrade though, afaik.
[1] http://news.ycombinator.com/item?id=5186245
[2] http://news.ycombinator.com/item?id=5186466
[deleted]
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.
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.
I suppose it is possible that programmers in Denmark are more skilled in crafting secure payment processes than Americans, but isn't it more likely that you're opinion is biased by a reporting bias? You are simply observing more reports of problems at US websites because they are so many more US websites than Denmarkian.
I don't believe that programmers in Denmark is more skilled, or more focused on security.
I have just often wondered why a lot of the webshops in the US that I use stores all my information, I have never seen it here.
And no, I don't believe that I use more US-based webshops than Danish.
I have just often wondered why a lot of the webshops in the US that I use stores all my information, I have never seen it here.
And no, I don't believe that I use more US-based webshops than Danish.
[deleted]
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_Secu...
We have laws that you must comply with if you store data: http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...
Not a law, its an industry standard. Its enforced by the card companies (Visa, etc) but generally only if you are processing enough transactions.
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.)
(This is why I always use a payment gateway and never keep details myself.)
Yeah, you can be fined, audited, have your merchant account revoked - all sorts of badness.
It's hard to say how that site was compromised though, isn't it? It could just as easily been a weak user password, or an Ubuntu vulnerability or any number of other vectors and then it wouldn't have mattered what the application was written in.
Members of our team have been receiving recruiter calls for the past few days - it seems a few places running Rails apps are on the lookout for developers to help secure and update their apps. At least one has apparently experienced the awesomeness of the Ruby way, and had their servers compromised.
Make the decision to move onto Python seem more correct every day.
Make the decision to move onto Python seem more correct every day.
The Python world has had very, very similar problems. Two popular Django add-ons (piston and tastypie) had remote code execution vulnerabilities due to the exact same cause as the recent Rails RCE vulns: insecure deserialization of YAML.
See https://www.djangoproject.com/weblog/2011/nov/
This isn't an exactly equivalent situation, since this wasn't a problem with the core Django framework --- but that's in part because the core Django framework does less. Functionality similar to these extensions is bundled with Rails.
See https://www.djangoproject.com/weblog/2011/nov/
This isn't an exactly equivalent situation, since this wasn't a problem with the core Django framework --- but that's in part because the core Django framework does less. Functionality similar to these extensions is bundled with Rails.
It is impossible to write insecure web applications in Python. /s
We don't seem to see the Python community embrace magic and shiny quite so much as in Ruby.
That alone seems to help.
That is subjective. What is "magic and shiny" and who is doing this embracing? "Magic and shiny" is embraced more in Sinatra than in Django? "Magic and shiny" is, by your definition, a security vulnerability?
2.5 years old issue https://twitter.com/coda/status/299732877745197056
Impressive.
Impressive.
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/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/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.
-----------
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/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/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.
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/
Heres a good read on timing attacks in general: http://codahale.com/a-lesson-in-timing-attacks/
"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...
Counting .. seems like a terrible way to solve this. Why not do a prefix match between the root of the public folder and File.expand_path(requested_path)?
I agree this seems really stupid. This is like 1998 era stuff. Put the path together, canonicalize it, then decide if you like it or not.
Your analysis of the first bug is correct.
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!
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!
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.
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) _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.
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) _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.
I imagine there's going to have to be a Rails release to upgrade the Rack versions used?
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.
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.
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?
Could the Ruby way become a bit safer and more secure in time?
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.
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.
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!
You mean Rails and not Ruby.
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).
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).
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.
Secure is not cool, nor magic enough, it seems.
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?
Rack is not Rails.
How many more of these are there out there? tens? hundreds? thousands?