

Rails 3.2.12, 3.1.11, and 2.3.17 have been released - DanielKehoe
http://weblog.rubyonrails.org/2013/2/11/SEC-ANN-Rails-3-2-12-3-1-11-and-2-3-17-have-been-released/

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

~~~
cwzwarich
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?

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

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

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

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

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

~~~
bratsche
Cool, thanks for the clarification Steve.

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

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

~~~
viseztrance
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!).

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

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

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

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

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

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

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

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

~~~
polemic
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!).

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

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

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

~~~
timr
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!

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

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

~~~
steveklabnik
I'm referring to
[https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...](https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-
security/G4TTUDDYbNA) , which I agree should have gone on the blog as well.
I'm not in control of that.

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

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

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

------
jasonshen
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?

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

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

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

~~~
emillon
Here they are on gmane:

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

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

------
6thSigma
Anyone know when 4.0 is coming out?

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

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

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

