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?
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.
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.
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.
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.
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.
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.
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?
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.
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.
"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 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!
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.
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?
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.
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!
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.
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?
How many more of these are there out there? tens? hundreds? thousands?