Rails 1.1.5: Mandatory security patch (and other tidbits)

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.

I’m getting a Zlib::BufError when it gets to actionpack

On 8/9/06, David Heinemeier H. [email protected] wrote:

The issue is in fact of such a criticality that we’re not going to dig

http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework


“Nothing will ever be attempted, if all
possible objections must first be
overcome.” - Samuel Johnson

“Luck is what happens when
preparation meets opportunity.” - Seneca

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

Bill

I am getting…

Install required dependency actionpack? [Yn]
ERROR: While executing gem … (Errno::ENOENT)
No such file or directory - getcwd

On Aug 9, 2006, at 1:14 PM, William G. wrote:

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

I should have included this info:

Platform: Windows XP
gem --version ==> 0.9.0
ruby --version ==> ruby 1.84 (2006-04-14) [i386-mswin32]

On 8/9/06, William G. [email protected] wrote:

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

Tom J. wrote:

I’m getting a Zlib::BufError when it gets to actionpack


“Nothing will ever be attempted, if all
possible objections must first be
overcome.” - Samuel Johnson

“Luck is what happens when
preparation meets opportunity.” - Seneca

On Thu, 10 Aug 2006, David Heinemeier H. wrote:

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

On Aug 9, 2006, at 19:41, [email protected] wrote:

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.

[email protected] wrote:

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

“In Ruby, no one cares who your parents were, all they care
about is if you know what you are talking about.”

  • Logan C.

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

Michael

On 8/9/06, [email protected] [email protected] wrote:

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

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

Stefan

This update worked fine for me on OS X.

And, even though there is quite a bit of crossover, shouldn’t this be
mentioned on the Rails ML as well?

Jeff

Thanks Stefan but no workie.

Michael

Matthew S. wrote:

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?

:slight_smile:


James B.

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

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.

On 8/9/06, David Heinemeier H. [email protected] wrote:

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.

yup it works now.
Thanks David :slight_smile:

– Tom


“Nothing will ever be attempted, if all
possible objections must first be
overcome.” - Samuel Johnson

“Luck is what happens when
preparation meets opportunity.” - Seneca

Also works for me now. Thanks David.

Michael

David Heinemeier H. wrote:

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.

On 8/9/06, David Heinemeier H. [email protected] wrote:

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 W.
http://johnwilger.com