From: Ed Howland <ed.howland@...>
Date: 2006-08-11T04:29:28+09:00
Subject: Re: [ANN] Rails 1.1.6: Stronger fix, backports, and full disclosure

David, what are the steps 3rd party engines need to do to fix their code?

Thanks
Ed

On 8/10/06, David Heinemeier Hansson <david.heinemeier@gmail.com> wrote:
> The cat is out of the bag, so here's the full disclosure edition of
> the current security vulnerability. With Rails 1.1.0 through 1.1.5
> (minus the short-lived 1.1.3), you can trigger the evaluation of Ruby
> code through the URL because of a bug in the routing code of Rails.
> This means that you can essentially take down a Rails process by
> starting something like /script/profiler, as the code will run for a
> long time and that process will be hung while it happens. Other URLs
> can even cause data loss.
>
> We've backported a fix to all the affected versions for those of you
> that can't update. You'll have to apply the diff for your version:
>
> * Patch for Rails 1.1.0:
> http://www.rubyonrails.org/files/aug_10_security/rel_1-1-0.diff
> * Patch for Rails 1.1.1:
> http://www.rubyonrails.org/files/aug_10_security/rel_1-1-1.diff
> * Patch for Rails 1.1.2:
> http://www.rubyonrails.org/files/aug_10_security/rel_1-1-2.diff
> * Patch for Rails 1.1.4:
> http://www.rubyonrails.org/files/aug_10_security/rel_1-1-4.diff
> * Patch for Rails 1.1.5: Upgrade to Rails 1.1.6.
>
> These patches (and 1.1.6) will break applications using the 3rd party
> engines idea. So if you can't upgrade because of dependencies to
> those, you can also add the following URL blocking while engines are
> being updated. Here's how to do it with mod_rewrite under Apache:
>
> RewriteRule ^(app|components|config|db|doc|lib|log|public|script|test|tmp|vendor)/
> - [F]
>
> Here's how to do it under lighttpd:
>
> url.rewrite-once = (
> "^/(app|components|config|db|doc|lib|log|public|script|test|tmp|vendor)/"
> => "index.html" )
>
> Unfortunately, the 1.1.5 update from yesterday only partly closed the
> hole (getting rid of the worst data loss trigger). After learning more
> about the extent of the problem, we've now put together a 1.1.6
> release that completely closes all elements of the hole (using the
> same technique as the backports above).
>
> So if you upgraded to 1.1.5 yesterday, you need to upgrade again. The
> approach stays the same:
>
>   sudo gem install rails --include-dependencies
>
> If you're running of trunk (also known as edge) using revision 4394 or
> later, you're not affected by all this in any form.
>
> We'll follow up with more information as it becomes available.
> Needless to say, this is all the Rails core team is working on right
> now and we've recruited a whole band of testers to help us play this
> out. We'll make sure to evaluate all the feedback that's been coming
> in and develop a policy for dealing with security issues in the
> future. Thanks for your continued understanding.
>
> We've also started #rails-security on Freenet for people with IRC
> available to get and share more information.
>
> If you're floating on gems (don't have vendor/rails), then make sure
> you update RAILS_GEM_VERSION in your config/environment.rb. Otherwise
> you'll still be bound to that earlier version of Rails even as you
> install the new gems.
>
>
> We continue to update http://weblog.rubyonrails.org/ with the latest
> information as it becomes available.
> --
> 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
>
>


-- 
Ed Howland
http://greenprogrammer.blogspot.com