
Update Rails or not – security issues either way - kasparloog
http://www.browserbite.com/rails-update-or-not-security-issues-either-way/
======
tptacek
No question: update Rails.

The security issues attributable to Rails upgrades are small in number and
relatively minor.

The security issues attributable to not upgrading Rails, and in particular in
not upgrading during upgrade cycles where the Rails community was reassuring
itself that everything was fine and that normal apps wouldn't be affected by
security flaws, are much larger in number and extremely significant.

If there was one lesson I'd hope people would take away from Rails Winter of
Security Madness, it is _be ready to patch at all times_. That's a good lesson
for every platform, not just Rails, but Rails teams now have specific reasons
to be on top of this.

When Rails announces security flaws, patch ASAP. If you're a professional
Rails team, dry-run this well in advance; _know_ you can patch at a moments
notice, don't just hope.

~~~
dasil003
How do you dry-run a Rails patch? I mean I know how to do `bundle update
rails`. The problems with updates tend to be patch-specific.

~~~
tptacek
If the only mechanism you have to update Rails is to do a "bundle update",
start by fixing that.

~~~
dasil003
Huh? No, I am familiar with Ruby development and use of git and patch files. I
still don't understand your point. How do you a dry-run of a patch that
doesn't exist?

~~~
tptacek
If you are seriously on top of Rails security, you're ready to deploy
workarounds if you have to, instead of waiting for the "tested" fix to
percolate into Ruby gems. So, start by making an innocuous but testable patch.
Add a class to ActiveSupport or something.

Also, when you drill this stuff (I think you should do it quarterly as soon as
you have customers), spend as much time drilling how you'll profile your
environment as you do in ensuring that your patch deployment is flawless. I
worry more about hidden stale deployments than I do about production app
servers.

~~~
static_typed
As you said above, "Rails Winter of Security Madness, it is be ready to patch
at all times" -- sounds a lot less fun than the five minute blog or scaffolded
apps that drew a lot of the Rails developers into the fold in the first place,
not realizing that a short while down the road they would be spending all
their time patching, monkey patching and crossing-fingers each time someone
lifts the hood on the framework and discovers yet another parser-in-a-parser
ready to exploit.

~~~
tptacek
I don't know what the heck one has to do with the other. Reliably, scalably,
securely deploying production applications is never going to be part of the
intro screencast for a platform.

Frankly, all your comments on this thread have shared a kind of language-war
tone; I'm talking about what people should be doing to secure production Rails
deployments, and you tack on a dig about a screencast from 2008. In other
parts of this thread, you leave wisdom like "Rails is for posers, Python for
pros". On the presumption that you are a good faith commenter writing this
stuff to evangelize for what you believe to be better platforms: the tactics
you're using are backfiring. Your comments are going light grey, and they're
discrediting the idea of evaluating platforms based on security by giving
Rails partisans an easy straw man to beat down.

------
tomkin
Do you know how many Rails developers I've heard pissing on Flash or Java and
its security vulnerabilities? Many - until recently. Now suddeningly these
faults are an accepted aspect of Rails development. Really. I guess this more
of a rant about how unfairly the Rails community (ie. dhh) has been on others,
but now expects critics to look away while it happens in the Rails community
on a weekly basis.

~~~
knowtheory
I'm guessing this schadenfreude must be delicious, since everyone keeps coming
back for additional helpings.

Look, gloating over other people's security issues is shitty behavior, and
frankly responsible developers don't do it. Am I calling DHH an irresponsible
developer? Yeah. But the Rails core team has thankfully incorporated a number
of smart and responsible developers over the past 4 years, and you see a whole
lot less shit like that.

Even better, security issues that have languished silently since 2006 are
being identified and quickly addressed.

So, no, nobody is asking anybody to look the other way. There are developers
who have been in the Ruby and Rails community for a long time, who make no
aspirations to being "rockstars" and are out spending their nights and
weekends patching rails, and are not slagging other people off for using Java.

Think of them when you feel the inclination to rant.

(also, incidentally, most of the ranting about Flash and Java development have
_not_ focused on security issues, they've mainly focused on how awful it is to
use those platforms to do development. Which is why things like JRuby are so
wonderful. You get to develop in Ruby, and access the JVM's system of
libraries.)

~~~
tomkin
I agree with most of what you said, but you accuse me of not thinking of the
RoR developer community, which is false. My issue lies with _extremely_
critical community leaders suddenly disappearing into the shadows. If you beat
others up, expect the same, is all. I don't relish the idea of picking apart
the community's hard work, but I do expect some fairness in the dialog.

------
jrochkind1
Rails _needs_ to produce security-patch-only patch releases.

This won't be foolproof; there is no such thing as foolproof in software
development. There can still be unintentional regressions in security-patch-
only releases (and even new security vulnerabilities), as well as new security
vulnerabilities in other releases.

Yes, nothing is foolproof. But you can work at improving your quality. Yes,
there are other things Rails could do to improve quality, including trying to
actually do some variation of semver.

But the most obvious thing with the highest benefit/cost that Rails team could
do is always release security patches in security patch only releases, so
developers can apply security patch only releases and minimize their exposure
to new regressions when doing so. Git should not make this hard to do, just
cherry pick the security-patch commits into a branch created off the last
release, and release it as a patch release seperately from any other changes.

Am I missing something?

~~~
jeremymcanally
Well, the release policy published by the Rails team states releases like this
are supposed to only have security patches, but for some reason it wasn't
followed here. I'm not sure why other than the frantic "zomg there's a
security hole must fix it!" fray that may have clouded their judgement.

------
bradleyland
Another option is to fork Rails and use the patch files (included with the
CVE) that target _only_ the vulnerabilities addressed in the CVE.

The problem with upgrading to mitigate security issues is that the Rails team
does not release security patches. They bump the minor-minor and do a release.
That release almost always includes commits that are unrelated to the security
issue. This is especially true when a lot of time passes between CVEs.

Maintaining your own branch really isn't that difficult, because you can
simply merge in from upstream. In most cases, you're really only interested in
patching from Rails team issued security fixes, so you won't have conflicts.
If you do have conflicts, you can safely overwrite anything in your fork,
because you're not developing Rails, you're simply maintaining tighter control
over the release that you use.

~~~
locofacetwice
Or don't use Rails.

~~~
static_typed
^^ This is good advice. Maybe they should question their choice of platform -
there are other options, some of which seem to have had a bit more forethought
in their architecture and engineering.

Remember: Ruby/Rails to pose, Python for pros.

~~~
sbank
> Remember: Ruby/Rails to pose, Python for pros.

How mature.

------
websitescenes
There is no such thing as an insurmountable security configuration. No matter
what you use or how you use it, there will always be new methods to compromise
your data. Hackers are creative and enjoy a challenge and will continually
attack systems until the end. Whether it be Rails or another framework, you
will have to upgrade and address security issues forever. Developers need be
realistic and understand that any system can be compromised if one tries hard
enough. I don't necessarily think that you should go from rails 2 to 3 or 3 to
4 just to address security features. Better off staying in the branch you
started the project in and applying the applicable patches for said security
concerns. With that said, RAILS RULES!!

------
sergiotapia
I've shared my sentiment here before on why I'm not going to use Rails
anymore. Imagine having your code working fine, and you update a MINOR version
3.2.x - and your ORM starts returning results that it didn't used to.

Heh.

Not worth the heartburn. I've switched to a saner, more tought out framework.
Rails is gorgeous, but not safe to use for any serious systems where you're in
a small team.

~~~
superuser2
What did you switch to?

~~~
innguest
Probably ASP.Net MVC -> <https://news.ycombinator.com/item?id=5410169>

------
mratzloff
So what was the issue from Rails, specifically?

~~~
knowtheory
Specifically that the security releases included changes to the way that
ActiveRecord works (which were unrelated to the security issues).

As a consequence, their search queries were scoped differently than what they
had intended. So their choice was roll back the security release, or modify
their app to accommodate ActiveRecord's altered behavior.

~~~
jrochkind1
Actually, ironically, the _particular_ bug that changed how ActiveRecord
works... which caused security problems... was actually an unintentional
regression in a _security patch_.

There were ALSO unrelated changes (quite many) in the patch release that
included the latest security fixes. Which is a mess.

But, the _particular_ problem here, the OP suggests it was the same problem as
github reported [here](<https://github.com/blog/1440-today-s-email-incident>),
where they suggest they isolated the introduction of the regression to [this
commit]([https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5...](https://github.com/rails/rails/commit/f980289fd2c1b9073a94b5d49b780a49f5e2933c#L1L23)),
which in fact has a commit message as the fix to CVE-2013-1854.

So, yes, a security fix unintentionally introduced a regression with _other_
security implications. Yeah, this is kind of ironic, and yeah, it means it's
not so simple to say what could have been done to avoid it. (In this case, I'm
surprised there wasn't an automated test already that caught the particular
regression. It seems like something that should have been tested. But I
haven't looked at the test source to see if it was an odd edge case or what
have you.)

(But it's STILL bad practice to release security patches only in releases
bundled with a bunch of other changes).

------
static_typed
Give a developer a Ruby-based web framework, and they can run for a day
without patching, but give them anything else - even Prolog on Punchcards -
and they run for so much longer!

Stop today, and help recovering Ruby developers onto a better path!

~~~
davesims
Your attempt to drive developers to Ruby and Rails by playing the role of a
typical ignorant anti-rails fundamentalist crusader will fail.

