On 8/9/06, John W. [email protected] wrote:
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 W.
But 1.1.5 also may have security holes, posted by me in:
http://www.ruby-forum.com/topic/76671
Could someone else, please, confirm them?
Are they known to Rails team?
Or 1.1.5 is about fixing another unrevealed bugs?
John W. wrote:
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.
On Thu, 10 Aug 2006, David Heinemeier H. 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.What Matthew said. We’ll release the details once everyone has had a
fair chance to upgrade.
It goes beyond that. To quote Paul L. (his comments can be seen in
their entirety here: On the total nondisclosure of the 8/9/06 security vulnerabil - Rails - Ruby-Forum)
"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 H.
On Fri, 11 Aug 2006, Christian N. wrote:
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:explanation of the rails security vulnerability in 1.1.4, others « evan weaver
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 H.
[email protected] writes:
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."
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:
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.
Just because there is a Rails core team that advises you to update,
there is no reason to think yourself. Given their authority, you
should believe what they say about Rails is true, but that won’t and
shouldn’t stop you from checking yourself.
So, let’s pretend for a moment that sometime within the next 24 hours,
an
“official” explanation of the patch comes out. We’ll then have seen the
following sequence:
- Rails team notices issue and fixes issue.
- Rails team issues patch and announces patch to community.
- Rails team pauses while patch disseminates through world. Developers
who are really concerned about what the patch might contain have
complete
access to changelogs and sourcecode and can figure out what’s being
changed. - Rails team explains patch withing 48 hours
This is good performance. Whether or not it’s open source or
commercial,
this is good performance. The pause while the patch was disseminated was
probably the right action (certainly, any other course of action would
have
been more questionable, and put more applications at risk).
They’ve given us an amazing framework, and they’re behaving responsibly.
I, for one, want to publicly say “Thank you.”
Bill
I totally agree! Thanks, Bill, for pointing this out!
Nicoolai
On Aug 10, 2006, at 12:04 PM, [email protected] wrote:
And AFAIK, despite there being information released from 3rd
parties, like that blog entry, about the vulnerability now, there
is still no official statement.
Why is it that folks happily use open source software at no cost and
then
seem to expect that the accouterments of a legal/business/customer
relationship
must also exist with the authors of the software?
Or is it the other way around? That the open source folks want all the
benefits of a legal/business/customer relationship with their users
but
don’t want to deal with any associated complaints/risks/liabilities?
It is probably a little of both.
Gary W.
I completely agree with Kirk. Especially considering that 1.1.5 patch
doesn’t really fix or opens another security vulnerability. I think
rails
core team should be more open when it comes to discovered
vulnerabilities.
An extra pair of eyes wouldn’t hurt with the evaluation of the fix.
On Aug 10, 2006, at 9:58 AM, William G. wrote:
who are really concerned about what the patch might contain have
would have
been more questionable, and put more applications at risk).They’ve given us an amazing framework, and they’re behaving
responsibly.I, for one, want to publicly say “Thank you.”
This is the fourth vulnerability that I know in Rails of but the
first that has been fully acknowledged as such. Two were DOSs (one
which I discovered, one which was co-discovered by my company), the
third was described as a DOS but potentially was a vulnerability of
the same severity as this one.
–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Nothing more to say:
The only issue I have is with not disclosing the nature of the
problem. Upgrading without testing just isn’t an option where I work.
If an application has to come down for adequate testing, that’s how
it’s done. We freeze the releases we run to the application, and in
some cases have applied patches against the source. Depending on the
nature of the problem, we could leave the applications up while we
test the new version of rails, or take them down if that was
necessary. However in a case like this we are flying blind. Not
disclosing the nature of the problem and it’s potential impact is
simply the wrong approach. I’m sure the core team made the decision
they thought was best, it just happened to be the wrong decision.
Chris
Eric H. wrote:
On Aug 10, 2006, at 9:58 AM, William G. wrote:
who are really concerned about what the patch might contain have
would have
been more questionable, and put more applications at risk).They’ve given us an amazing framework, and they’re behaving
responsibly.I, for one, want to publicly say “Thank you.”
This is the fourth vulnerability that I know in Rails of but the
first that has been fully acknowledged as such.
There’s another one open:
http://wrath.rubyonrails.org/pipermail/rails-core/2006-July/002077.html
It’s not as easily exploitable as the one that was fixed in 1.1.5, but
depending on the application it can be very dangerous, e.g. if the
string is used in a system call or in a SQL statement. I posted the
description and a fully tested and documented patch on the Rails-Core
list and on the bug tracker more than two weeks ago, with the tag
“Security” in the subject, but so far there hasn’t even been a reaction
from the core developers.
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.
On Aug 10, 2006, at 7:43 AM, Rakesh M. wrote:
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?
–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Without ZenTest, wouldn’t the tests have failed before the Rails update?