How many more of these are there out there? tens? hundreds? thousands?
But on the discussion we had before, this one does not seem to affect Rails:
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.
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 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.
We have laws that you must comply with if you store data: http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...
(This is why I always use a payment gateway and never keep details myself.)
Make the decision to move onto Python seem more correct every day.
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.
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.
The second bug seems to have to do with `==` not being safe and them having to do a "secure compare":
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.
Heres a good read on timing attacks in general:
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!
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.
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.
Could the Ruby way become a bit safer and more secure in time?
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.
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).
Secure is not cool, nor magic enough, it seems.