[ANN] Rails 1.1.5: Mandatory security patch (and other tidbits)

[David Heinemeier Hansson]

We're still hard at work on Rails 1.2, which features all the new
dandy REST stuff and more, but a serious security concern has come to
our attention that needed to be addressed sooner than the release of
1.2 would allow. So here's Rails 1.1.5!

This is a MANDATORY upgrade for anyone not running on a very recent
edge (which isn't affected by this). If you have a public Rails site,
you MUST upgrade to Rails 1.1.5. The security issue is severe and you
do not want to be caught unpatched.

The issue is in fact of such a criticality that we're not going to dig
into the specifics. No need to arm would-be assailants.

So upgrade today, not tomorrow. We've made sure that Rails 1.1.5 is
fully drop-in compatible with 1.1.4. It only includes a handful of bug
fixes and no new features.

For the third time: This is not like "sure, I should be flooshing my
teeth". This is "yes, I will wear my helmet as I try to go 100mph on a
motorcycle through downtown in rush hour". It's not a suggestion, it's
a prescription. So get to it!

As always, the trick is to do "gem install rails" and then either
changing config/environment.rb, if you're bound to gems, or do "rake
rails:freeze:gems" if you're freezing gems in vendor.

P.S.: If you run a major Rails site and for some reason are completely
unable to upgrade to 1.1.5, get in touch with the core team and we'll
try to work with you on a solution.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

 

[William Grosso]

Me too. I'm on Windows, if that matters (does it work on other
platforms) ?


Bill

 

[James Edward Gray II]

Me too. I'm on Windows, if that matters (does it work on other
platforms) ?

I did update successfully on Mac OS X.

James Edward Gray II

 

[khaines]

This is a MANDATORY upgrade for anyone not running on a very recent
edge (which isn't affected by this). If you have a public Rails site,
you MUST upgrade to Rails 1.1.5. The security issue is severe and you
do not want to be caught unpatched.

The issue is in fact of such a criticality that we're not going to dig
into the specifics. No need to arm would-be assailants.

This seems misguided to me. One of the things that I have always
appreaciated about the general open source environment is that when
there is a security vulnerability it is announced. It is described.
And it is fixed.

The process is open, and it works because someone can go and look at
the information about the vulnerability and learn from it, and they can
have faith in the advice to upgrade because the vulnerability
announcement is clear about what the exploit is and the risk from it.


Kirk Haines

 

[Kent Sibilev]

This seems misguided to me. One of the things that I have always
appreaciated about the general open source environment is that when
there is a security vulnerability it is announced. It is described.
And it is fixed.

The process is open, and it works because someone can go and look at
the information about the vulnerability and learn from it, and they can
have faith in the advice to upgrade because the vulnerability
announcement is clear about what the exploit is and the risk from it.

+1

 

[Matthew Smillie]

This seems misguided to me. One of the things that I have always
appreaciated about the general open source environment is that when
there is a security vulnerability it is announced. It is
described. And it is fixed.

The process is open, and it works because someone can go and look
at the information about the vulnerability and learn from it, and
they can have faith in the advice to upgrade because the
vulnerability announcement is clear about what the exploit is and
the risk from it.

There are competing interests at stake beyond adhering to general
open-source philosophy. If, for example, a vulnerability is very
easily exploited, and could cause data loss or other significant
damage, there's a very strong case to be made for fixing first and
giving explicit documentation later.

In other words, if you lose your entire database two hours after the
announcement (because it was announced at 2am local time, say), it's
pretty cold comfort that the vulnerability was openly discussed and
evaluated according to all the best practices of the open-source
community.

In any case, the only thing missing is a spoon-fed description of the
vulnerability. The fix itself is public, and if you're into that
sort of thing, I'm sure you could get a good idea of the exploit by
examining changes to the source code.

matthew smillie.

 

[James Britt]

This seems misguided to me. One of the things that I have always
appreaciated about the general open source environment is that when
there is a security vulnerability it is announced. It is described. And
it is fixed.

The process is open, and it works because someone can go and look at the
information about the vulnerability and learn from it, and they can have
faith in the advice to upgrade because the vulnerability announcement is
clear about what the exploit is and the risk from it.

I agree. I understand there's value in insisting on applying the
upgrade rather than going into detail; people may decide that they can
simply patch the code themselves, or misunderstand the security risk and
put off the upgrade.

But that should be the individual's call.

Besides, if one does a diff from 1.1.4 and 1.1.5, wouldn't the problem
be exposed anyway? Security through obscurity is not going to be a big
hindrance to people intent on doing bad things. The cat's out of the bag.



--
James Britt

"In Ruby, no one cares who your parents were, all they care
about is if you know what you are talking about."
- Logan Capaldo

 

[Michael Trier]

Also getting the Zlib::BufError problem on Windows. Advice?

Michael

 

[Stefan Klasen]

As mentioned in the rubyonrails weblog a "gem install rubyzip" should fix it.

Stefan

 

[Michael Trier]

Thanks Stefan but no workie.

Michael

 

[James Britt]

In other words, if you lose your entire database two hours after the
announcement (because it was announced at 2am local time, say), it's
pretty cold comfort that the vulnerability was openly discussed and
evaluated according to all the best practices of the open-source
community.

Good point. I think what may have been irksome is the perception of the
initial post as saying, "I'm not telling you the details; trust me, it's
for your own good."

Which may be essentially true, but at some point (and it will happen one
way or the other) a discussion of the details is needed.

In any case, the only thing missing is a spoon-fed description of the
vulnerability. The fix itself is public, and if you're into that sort
of thing, I'm sure you could get a good idea of the exploit by
examining changes to the source code.

It's not on /. yet?

Or warezonrailz.ru?



--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys

 

[David Heinemeier Hansson]

There are competing interests at stake beyond adhering to general

open-source philosophy. If, for example, a vulnerability is very
easily exploited, and could cause data loss or other significant
damage, there's a very strong case to be made for fixing first and
giving explicit documentation later.

In other words, if you lose your entire database two hours after the
announcement (because it was announced at 2am local time, say), it's
pretty cold comfort that the vulnerability was openly discussed and
evaluated according to all the best practices of the open-source
community.

What Matthew said. We'll release the details once everyone has had a
fair chance to upgrade.

BTW, there was a problem with the gem of Action Pack which caused
issue when trying to install on Windows (RubyGems recorded the wrong
size for the gem). We've replaced the gem with one of proper meta
data, so you should be good to go on redownloading shortly.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.backpackit.com -- Personal information manager
http://www.rubyonrails.com -- Web-application framework

 

[Michael Trier]

Also works for me now. Thanks David.

Michael

 

[James Britt]

What Matthew said. We'll release the details once everyone has had a
fair chance to upgrade.

BTW, there was a problem with the gem of Action Pack which caused
issue when trying to install on Windows (RubyGems recorded the wrong
size for the gem). We've replaced the gem with one of proper meta
data, so you should be good to go on redownloading shortly.

Thanks for getting this patch out.

 

[John Wilger]

The issue is in fact of such a criticality that we're not going to dig
into the specifics. No need to arm would-be assailants.

Sorry, but this is ridiculous.

Maybe you don't release the exact instructions for how to fix the
vulnerability at this time, but without any more details than this,
how can any business make an informed decision on whether we really
need to spend time upgrading every one of our Rails applications
_right now_.

Will this vulnerability allow someone to take control of our server
and gain network access (high risk for us), or would it just cause our
application to crash (low risk for the majority of what we have in the
works at the moment)? Does this only affect certain packages or
features, or is it a defect in the core of the system?

No software is totally secure. Security is about evaluating risk and
taking precautions up to a certain point where you start getting
diminishing returns. That point is different for every organization
and project.

Not releasing any more details than this _could_ have a negative
effect on the number of applications that get upgraded right away,
because we don't have enough information to evaluate what the true
risk is.

--
Regards,
John Wilger
http://johnwilger.com

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
- Lewis Carrol, Alice in Wonderland

 

[John Wilger]

Maybe you don't release the exact instructions for how to fix the
vulnerability at this time

Doh! By "fix" I mean "exploit". Obviously, you told us how to fix it.


--
Regards,
John Wilger
http://johnwilger.com

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
- Lewis Carrol, Alice in Wonderland

 

[Cliff Cyphers]

Sorry, but this is ridiculous.

Maybe you don't release the exact instructions for how to fix the
vulnerability at this time, but without any more details than this,
how can any business make an informed decision on whether we really
need to spend time upgrading every one of our Rails applications
_right now_.

Care to spend some time looking into files that have changed between
builds? Here's a list:

http://cyphers.dns2go.com/cliff/rails_diff.txt

Results need about 100 colums and is too wide for standard email and
would have formatting issues posting directly.

 

[khaines]

What Matthew said. We'll release the details once everyone has had a
fair chance to upgrade.

It goes beyond that. To quote Paul Legato (his comments can be seen in
their entirety here: http://www.ruby-forum.com/topic/76671)

"The nondisclosure policy in handling this vulnerability has
seriously jeopardized our (and many other people's) ability to use Rails
in a commercial environment, so we would like to suggest that it be
changed.

The core issue is that releasing a patch to fix a critical security
vulnerability without telling anyone what the vulnerability is does very
little good as a knowledgeable cracker can just SVN diff the new version
with the old one and peruse that patch to have an exploit ready to go."

I have software running in environments where it has a real effect on the
business operations and their bottom line. I have Ruby software running
in financial environments and for a Fortune 500 financial company.

I don't use Rails for these things, so this vulnerability doesn't directly
affect me, but the way that it has been handled certainly does, and here's
why:

One of my pieces of software is a custom data storage and retrieval system
for a company that handles products that I bet most of you reading this
have seen or maybe even posessed before. They load into this system
inventory and product data as well as contact and sourcing data. The
availability of the system is very important with regard to their ability
to efficiently serve their customers.

Imagine the president of this company, who knows that his software is
implemented with Ruby, hears about this critical, greivous security issue
with Ruby/Rails. He goes and finds the announcement, which says nothing,
really, except to trust you and upgrade now. So, he comes to me with a
great deal of concern and asks me about it.


--Is his software vulnerable?

++Well, no, because it's not using Rails.

--Okay, well, what is the vulnerability?

++I have no idea.

--Okay, then how do you know that your code doesn't have the same problem?
It's written with Ruby, too, right?

++Yes, but it's not Rails.

--So? If you don't know what the vulnerability actually is, how do you
know your code doesn't have it, too? Maybe it's in some other library
that both Rails and your code uses or something.

++You're right. I have no idea.


Yeah, there are logical ways out of a conversation like that, but when
dealing with situations where the decision to use Ruby at all on a
potentially sensitive business application could come under question, this
"we aren't saying a word except that it's horrible, but trust us" approach
by the Rails core team doesn't, in the long run, help themselves or any of
the rest of us.

No imagine that it's not a $5 million a year company doing the
questioning, but the security team of that Fortune 500 financial company
(a very conservative market) who is currently performing a mandatory
security audit? The lack of a clear announcement of the vulnerability
does little to enhance the security of Rails users, and does a lot to
create doubt and suspicion in the minds of people who have the power to
make decisions about whether Ruby, in general, is an appropriate tool for
their enterprise.


Kirk Haines

 

[khaines]

Alternatively, you (or everyone else with a bit experience of Ruby)
can svn diff yourself. Or, you can search for third-party information
about the hole, and soon will find something like:

http://blog.evanweaver.com/articles...-rails-security-vulnerability-in-1-1-4-others

There you have a clear explanation which you can prove by looking at
the code yourself, see if your own application is affected (of course
it's not, you do the routing thing in a sane way) and have learned
something for the future.

I fully agree, and fortunately this is a simple one to go and figure out
for oneself. But my criticism lies more with the general philosophy. It
still opens a potential can of worms (as Evan points out in that blog
entry under Criticism at the bottom of it), and it doesn't actually help
anyone.

And AFAIK, despite there being information released from 3rd parties, like
that blog entry, about the vulnerability now, there is still no official
statement.

It's stupid, but when I'm addressing questions from the president of a
company, he puts more credibility behind official explanations from the
source than from random (to his eyes) 3rd party analysis.

I'll drop it, because what's done is done, and my opinion isn't likely to
change, but I truly hope that future vulnerabilities that are discovered
with any Ruby web framework, or anything else in the Ruby world, will be
handled with greater openness.



Kirk Haines

 

[Eric Hodel]

This killed all of my functional tests:

ENV["RAILS_ENV"] = "test"
require File.expand_path(File.dirname(__FILE__) + "/../config/
environment")
require 'test/rails'
require 'test_help'

Suddenly, 'test/rails' doesn't exist.

test/rails is part of ZenTest. You do have the ZenTest gem
installed, correct?