Rails 3.2.12, 3.1.11, and 2.3.17 have been released | Hacker News Reader

Rails 3.2.12, 3.1.11, and 2.3.17 have been released

weblog.rubyonrails.org

136 pointsDanielKehoe61 comments

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.

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 just patched a project by updating the Gemfile with the latest Rails version and "bundle update rails" updated the json gem along with it.

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.

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'

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/).

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?

For example, https://github.com/rails/rails/pull/8718 is a PR that was merged into 3-2-stable to deal with a regression in 3.2.8.

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.

Cool, thanks for the clarification Steve.

I know we shouldn't rely on security by obscurity but I hope people will stop posting proof of concepts within the first 24 hours of the announcement.

What, then we'll have to work for a living? Good thing I hadn't had anything planned this evening. :P

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.

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.

If there were no PoC, significantly fewer would patch, and even those that did patch would have a hard time verifying that their patch worked.

Meh. I don't use attr_protected anyway, and neither should anyone else. Security 101 - whitelist, don't blacklist.

That said the JSON issue looks worrying, so an update and redeploy is necessary.

I've already switched to using the strong_parameters gem. I'd recommend it to anyone else starting a new rails 3 project.

+1 to this. For new projects I'd probably just go with 4.0 beta though, it's almost ready...

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.

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".

This would not happen if Rails were not such a Goliath due to its popularity and in many circles, status as the 'one true framework.'

> 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.

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!

So, why did the Rails maintainers arbitrarily decide to stop supporting 3.0.x versions, while still supporting 2.3.x versions?

because it's easy to upgrade to 3.2

Many people get stuck at the (X-1).Y release of x.y.z versions. This is because upgrading x-1 to x can be difficult and costly.

So there's a good reason to support both x and x-1, but less of a good case to support y, y-1, AND y-2: those people can more easily upgrade to y-1.

So, as you can see, it's not arbitrary: x and x-1 are supported, y and y-1 are supported. Just no series as of two revisions ago.

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 can call any decision 'arbitrary,' I guess. I mean it has internal logic.

Notice was given, in the post spelling out which versions are still supported a few weeks ago.

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.

I'm referring to https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... , which I agree should have gone on the blog as well. I'm not in control of that.

This is their maintenance policy: https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

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.

Updating Rails (an article with details and advice):

http://railsapps.github.com/updating-rails.html

Let me know if I got anything wrong. It's for anyone who is not sure how to upgrade to a new Rails version.

The release text is not that clear. Is that a new big security issue?

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.

You should also update your JSON gem.

The CVEs go into more detail. There's a way to circumvent attr_protected.

Noob question: I just installed the newest version of rails with "gem install rails" but when I run "rails -v" I stil get 3.2.11

How do tell the computer to start using the newest version of Rails?

'bundle update rails' should do it subject to your Gemfile specifying a particular version.

Updated the Gemfile and ran this command. Worked. Thanks!

Change your Gemfile so it says "gem 'rails', '~> 3.2.12'"

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.

Thanks!

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. :-)

http://ruby.railstutorial.org/ruby-on-rails-tutorial-book#se...

    $ gem install rails -v 3.2.12

https://github.com/railstutorial/sample_app_2nd_ed/blob/mast...

    gem 'rails', '3.2.12'

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!

Have you tried uninstalling the earlier versions before downloading the new one?

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.

Here they are on gmane:

[CVE-2013-0276]: http://permalink.gmane.org/gmane.comp.security.oss.general/9...

[CVE-2013-0277]: http://permalink.gmane.org/gmane.comp.security.oss.general/9...

Anyone know when 4.0 is coming out?

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.

I completely agree. I just heard the release date was imminent back in December. I assume these security bugs are what's postponing it.

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.

Except the internet would still have you to start flamewars about people you didn't like! :P

Make no mistake, there are a pile of ruby programmers who do care about security and take this shit seriously. You probably use their code.

We're paying for the way that Rails was developed in the days prior to the Rails/Merb merge. There's a reason why the community split in those days.

Please don't paint all of us Rubyists with the same brush.

There is no official date for 4.0. "When it's ready."

That's good. The RoR community is very conservative about these things and makes sure to only release after thorough testing.

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.

Reply on news.ycombinator.com