Please also note from the blog post that CVE-2013-0269 refers to the "json" gem, which may not get upgraded with the rails gem updates. You may need to add it as a separate dependency to your Gemfile to make sure you are using json version 1.7.7, 1.6.8, or 1.5.5.
There are two common json gems, one if which is NOT updated when you update rails. json_pure does not seem to be updated to 1.7.7 automatically by 'bundle update rails' so if your Gemfile.lock shows your app uses json_pure (via some other gem's dependency in my case), you also need to run 'bundle update json_pure'
Shouldn't there be a way for gems maintainers to force/strongly encourage an upgrade when there is a security issue regardless of the transitive nature of the dependency?
I think it depends a lot on your particular configuration, since json is only an indirect dependency in rails (i.e. it's not part of rails's gemspec). It's clear that it won't get updated for everyone, which is why this warning (to make sure json gets updated and possibly add the dependency if needed) has gone out on the rails security mailing list.
It is also important to note that at least the 3.2.12 release forces you to upgrade rack too. This is due to seperate vulnerabilities reported in rack recently (see http://rack.github.com/).
Why? The PoC makes it easy to test your apps with tools like Metasploit. The blackhats don't care. They're going to build a sploit anyway, and they're not going to share it so we can use it to test.
There are many smaller targets and this lowers the barrier for script kiddies to an unprecedented level.
And it's one thing to detect the exploit and another to actually run it and post it on the web before people have time to patch their installations (talking about hours!).
I know this line of reasoning is tempting, but it simply doesn't hold up under scrutiny. Even scriptkiddies know where to get "sploits". The difference is, we won't get those as part of our security tool subscription, so we won't have an easy way to test. There's no hiding when the necessary patches point out exactly where the vulnerability is. Your only choice is to patch immediately. Lamenting the availability of PoC tools for whitehats isn't going to reduce your chances of being hit by a blackhat one iota.
I'm not against work. I just realise that my collegue who access to deploy our app is in Japan and won't get up for a few hours. It's just common sense.
There have been other commits that made it into the 3-2-stable branch, and I would have expected that those fixes would have made it into the next 3.2.x release, but that's not the case. Is that normal for Rails updates?
It is my understanding that security updates are generally made by taking the last released version, applying the security patches, releasing, and then applying the patches to the end of 3-2-stable.
This makes it incredibly easy for people to upgrade, and minimizes chances of regressions.
The next non-security release of 3.2.x should include that change.
I can't completely agree with that. I spent some time with 4.0 with the intention of building on it but found too many broken Gems to be productive with it. If you don't intend to use many (or any) third-party Gems it's less of a problem.
This is really wonderful work, both from the investigators who've documented and described the vulnerabilities and the Rails folks for being quick to fix them.
My co-founder and I had talked about YAMLgate when it had happened--our conclusion was that Rails is going to be under very close scrutiny for a while, and that there will be a lot of these things found, but that the framework will be all the stronger for it.
Always bear in mind this: even if it means more work for admins and devs, this promptness of response and willingness to admit failings is a sign of a healthy ecosystem.
Can anyone explain why boosterism gets upvoted so much on these RoR vuln posts?
RoR maintainers should be commended for their ongoing prompt responses to defects, but the likelihood ...that there will be a lot of these things [still to be] found... is not something to celebrate.
Every project has bugs, every framework has it's security problems, but the severity and frequency of the issues is such that many will conclude that RoR is not mature, stable or safe enough for production use.
I can only conclude that a large proportion of HN readers have most of their eggs in the RoR basket, so spinning this into a positive is the best way to convince themselves that "..more work for admins and devs.." is a GOOD thing.
> Can anyone explain why boosterism gets upvoted so much on these RoR vuln posts?
I don't have an answer for that. Not to discount the work people do, but it feels weird to celebrate the existence of severe vulnerabilities because of the effort that goes into patching them. Perhaps the point is that the framework becomes more secure and vetted, but that's not something that can really be measured in that way, and a lot of observers will view the existence of so many high-profile vulnerabilities as a sign of poor design decisions.
I'd be doing the same thing if there was an announcement about Khronos fixing the perennial retardation of the OpenGL API, or of a new batch of bugfixes for some of the Java stuff I used to use, or whatever else--I'd support them all the same.
Anything that helps encourage people to be open about their work and honest in their failings in our industry is, in my book anyways, a Good Thing.
Don't be hating on Ruby folks for trying to encourage good development practices.
From a triage point of view, Ruby/RoR is excellent. I'm not trying to hate on Ruby people - the community is amazing and the inherent openness and transparency is to be lauded.
That's not my issue though. The project's reputation is fiercely protected by it's community - and I wonder at what point this could be damaging. To borrow some terminology, they're not `user-space` bugs like the majority of PHP security flaws (for example). They're bugs in the firmament.
Talking to penetration testers, you often hear this story: if it's .NET, you're going to have a hard time; If it's PHP, you can count on the developer leaving an injection flaw of varying exploitability; If it's RoR, you can count on an out of date package with a critical flaw that bypasses the app entirely. (btw: I'm primarily a python/django person - I won't comment on that!).
This is a classic concern troll. If you're not interested in RoR, don't click on threads about RoR. If you do, don't come in and tell people to stop thanking people for their hard work to fix security issues.
> Talking to penetration testers, you often hear this story: if it's .NET, you're going to have a hard time; If it's PHP, you can count on the developer leaving an injection flaw of varying exploitability; If it's RoR, you can count on an out of date package with a critical flaw that bypasses the app entirely.
Do any real life pentesters here on HN concur with this summary?
I posit the opinion that Rails is a framework in shambles that is good for nothing greater than a contact form far out-ways many others on HN, which is why there is a relativisation.
These discussions are usually filled with snark and people feeling righteous in their own framework choices, smiling and generalizing about the entire Ruby community. So there's a chasm between people saying "your framework sucks and you should feel bad" and people saying "ok this is actually a good thing".
Because the PR machine for Rails is big, and people are slow to admit they sometimes back the wrong horse.
Yes - well done devs for the quick turnaround in fixes.
No - constant sticky plaster patch fixes are not the same as proper design, security concerns, software engineering.
Less magic, and more security thought would be good!
I was about to post complaining that releasing a 2.3.x and releasing a 3.0.x was against their recently announced policy, but I thought I would double check and found that 3.0.x isn't covered for "Severe security issues".
Aside from the fact that this seems rather strange (to say the least), I'm guessing a lot of other people misread the policy too and simply assumed that 3.0.x would be patched if 2.3.x was.
It's fairly arbitrary. There were changes between Rails 3.0.x and 3.1.x that broke many popular gems (e.g. Devise). A lot of people get stuck at that transition, because it's difficult and costly.
This just seems like laziness. At the very least, you don't just suddenly choose to end-of-life a version of software that's still in wide distribution. Give people a bit of notice!
You really think that's a fair response? There was a parenthetical mention that "this will be the last release of the 3.0.x series" in the middle of a blog post about a critical security fix on the 28th of January. I don't recall any notice before that.
Even if the announcement weren't buried, most of us have development schedules that don't incude the spare time to completely upgrade our infrastructure with two weeks of lead time.
There's no real reason that this couldn't have been announced a few months in advance. I know that this is an open-source project, but one of the costs of having the immense privilege of users who depend on your project is that you make real efforts to give them a little notice before you deprecate their world.
These are new security issues that are mostly related to the latest yaml problems. The issues are explained in detail in the linked CVE. One of the issues affects only rails < 2.3.17, but the second is critical enough to warrant immediate updates unless you're sure you're safe.
Ah that's it. I'm going through mhartl's Ruby on Rails Tutorial and he has us specify a Rails version to maintain consistency btw the tutorial and our code.
I use exact gem versions because experience shows that even minor gem updates can break the tutorial. (RSpec is particularly guilty of this.) I generally recommend '~>' for more advanced users, but when getting your bearings I think it's best to use exact versions.
That said, I keep the Rails Tutorial and sample application as up-to-date as possible—and in fact both have already been updated with the latest version. :-)
Great to see you here Michael. I guess the gap between when I started the Tutorial and when you updated it accounts for the difference. Currently on Chapter 7!
Does anyone have a copy of the CVEs that's not on Google Groups? Something in the js or cookie-handling is broken for me and the page includes no text.
Most of these security vulnerabilities are "stop what you're doing right now and fix this" bugs.
Honestly I don't want a Rails 4 until all the rest of this has been shaken free. I'd rather Rails-core and other security minded rubyists keep digging for exploits.
There are so many security issues being unveiled that at this point one might wonder if Rails 4 (and a complete redesign) may not be the way to fix the security issues.
Maybe also, if ruby programmers learned to program (instead of doing banana driven lingo development) or committed suicide throwing themselves from a cliff (along with PHP developers) (like lemmings) we could also have a boring yet more secured internet.
Your snark isn't very helpful. Every major release goes through a few release candidates. For example, 3.0.0 had 4 beta and 2 RC releases before final. 3.2.0 had two RCs.
