David Heinemeier Hansson 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.
--
James Britt
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 8/10/06, Dmitry Severin <dmitry.severin@gmail.com> wrote:
But 1.1.5 also may have security holes, posted by me in:
On the total nondisclosure of the 8/9/06 security vulnerabil - Rails - Ruby-ForumCould someone else, please, confirm them?
Are they known to Rails team?
Or 1.1.5 is about fixing another unrevealed bugs?
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
On Thu, 10 Aug 2006, David Heinemeier Hansson 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.
Thanks Stefan but no workie.
Michael
Also works for me now. Thanks David.
Michael
khaines@enigo.com 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.
--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org
test/rails is part of ZenTest. You do have the ZenTest gem installed, correct?
On Aug 10, 2006, at 7:43 AM, Rakesh Malik 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.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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
On Fri, 11 Aug 2006, Christian Neukirchen 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: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.
Without ZenTest, wouldn't the tests have failed before the Rails update?
On 8/10/06, Eric Hodel <drbrain@segment7.net> wrote:
On Aug 10, 2006, at 7:43 AM, Rakesh Malik 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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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 Wright
On Aug 10, 2006, at 12:04 PM, khaines@enigo.com 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.
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 8/10/06, khaines@enigo.com <khaines@enigo.com> wrote:
On Fri, 11 Aug 2006, Christian Neukirchen 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:
>
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 Haines
--
Kent
---
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:
1. Rails team notices issue and fixes issue.
2. Rails team issues patch and announces patch to community.
3. 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.
4. 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
gwtmp01@mac.com wrote:
On Aug 10, 2006, at 12:04 PM, khaines@enigo.com 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 Wright
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
I totally agree! Thanks, Bill, for pointing this out!
Nicoolai
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.
On Aug 10, 2006, at 9:58 AM, William Grosso wrote:
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:1. Rails team notices issue and fixes issue.
2. Rails team issues patch and announces patch to community.
3. 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.
4. Rails team explains patch withing 48 hoursThis 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."
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Nothing more to say:
Eric Hodel 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.