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 Hansson <david.heinemeier@gmail.com> wrote:
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
--
"Nothing will ever be attempted, if all
possible objections must first be
overcome." - Samuel Johnson
"Luck is what happens when
preparation meets opportunity." - Seneca
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
···
On Thu, 10 Aug 2006, David Heinemeier Hansson 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.
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.
···
On 8/9/06, David Heinemeier Hansson <david.heinemeier@gmail.com> 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.
--
Regards,
John Wilger
-----------
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
Me too. I'm on Windows, if that matters (does it work on other
platforms) ?
Bill
Tom Jordan wrote:
···
I'm getting a Zlib::BufError when it gets to actionpack
On 8/9/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:
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
On 8/9/06, khaines@enigo.com <khaines@enigo.com> wrote:
On Thu, 10 Aug 2006, David Heinemeier Hansson 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.
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.
···
On Aug 9, 2006, at 19:41, khaines@enigo.com wrote:
On Thu, 10 Aug 2006, David Heinemeier Hansson 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.
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
Doh! By "fix" I mean "exploit". Obviously, you told us how to fix it.
···
On 8/9/06, John Wilger <johnwilger@gmail.com> wrote:
Maybe you don't release the exact instructions for how to fix the
vulnerability at this time
--
Regards,
John Wilger
-----------
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
On 8/9/06, David Heinemeier Hansson <david.heinemeier@gmail.com> 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_.
Care to spend some time looking into files that have changed between builds? Here's a list:
Install required dependency actionpack? [Yn]
ERROR: While executing gem ... (Errno::ENOENT)
No such file or directory - getcwd
···
On 8/9/06, William Grosso <wgrosso@wgrosso.com> wrote:
Me too. I'm on Windows, if that matters (does it work on other
platforms) ?
Bill
Tom Jordan wrote:
> I'm getting a Zlib::BufError when it gets to actionpack
>
> On 8/9/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:
>> 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
>>
>
And, even though there is quite a bit of crossover, shouldn't this be
mentioned on the Rails ML as well?
Jeff
···
On 8/9/06, Matthew Smillie <M.B.Smillie@sms.ed.ac.uk> wrote:
On Aug 9, 2006, at 19:41, khaines@enigo.com wrote:
> On Thu, 10 Aug 2006, David Heinemeier Hansson 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.
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.
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.
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.
On 8/9/06, David Heinemeier Hansson <david.heinemeier@gmail.com> 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.
--
"Nothing will ever be attempted, if all
possible objections must first be
overcome." - Samuel Johnson
"Luck is what happens when
preparation meets opportunity." - Seneca
