Major Security Hole Found In Rails

mudimba writes "A major security hole has been found in Ruby on Rails. Upgrading to version 1.1.5 is extremely urgent, and all previous versions except those "on a very recent edge" are affected. Details on the exact nature of the flaw will be coming soon, but the rails team has decided to wait a short time before disclosure so that people can have a chance to upgrade their servers before would-be-assailants are armed." Update: 08/10 13:56 GMT by J : Now they're saying only the last six months of releases are affected: 1.1.0 through 1.1.4.

Comments

Re:Is it related to previous fixes...?

[leenks]

Good news: Rails 1.0 and prior is not affected by the latest security breach we've experienced. Neither is Rails 1.1.3. We're currently investigating further just how contaminated 1.1.0, 1.1.1, 1.1.2, and 1.1.4 are.

"RTFA suddenly seemed like a good idea."

Re:RoR lacks maturity

[morgajel]

yes, because we know no one else gets security holes. Writing something off because the authors jump up and down and say "holy shit, patch this" is a bit short-sighted. at least people are being informed and shit is being done about it.

Details of the exploit can be found here.

[Anonymous Coward]

http://blog.evanweaver.com/articles/2006/08/10/exp lanation-of-the-rails-security-vulnerability-in-1- 1-4-others

Patch details

[Wulfstan]

$LOAD_PATH.select do |base|
                              base = File.expand_path(base)
                              extended_root = File.expand_path(RAILS_ROOT)
- base[0, extended_root.length] == extended_root || base =~ %r{rails-[\d.]+/builtin}
+ base.match(/\A#{Regexp.escape(extended_root)}\/*#{ file_kinds(:lib) * '|'}/) || base =~ %r{rails-[\d.]+/builtin}
                          end

Not seen the context (so this is guesswork), but looks suspciously to me like you could supply a path like;

RAILS_ROOT/../../../../etc/passwd

Or something substantially similar to it...

Re:Patch details

[ubernostrum]

Nope. $LOAD_PATH contains the directories Ruby searches for libraries (@INC in perl, I don't know the equivalent in Python).

sys.path in Python, which is initialized from the environment variable PYTHONPATH.

It's doubtful Rails would have a '../../etc/passwd' type bug since very few of the urls have any direct correspondence to the filesystem. (e.g. mail/send/1 executes the send method of an instance of the MailController class).

But... the default setup for Rails (or at least, last time I played with it) is to map /controller/action/-style URLs for you, so if you managed to upload a Ruby file which just happens to contain your malicious subclass of ActionController, well, you'd pretty much own the site.

This is why I don't like automatic URL mapping; only the URLs I've explicitly laid out should ever respond, and only the code I've explicitly pointed them to should ever be executed. I know Rails has other ways of mapping your URLs, but I don't know off the top of my head if you can disable the default controller-name/action-name mapping; even scarier is that a number of other frameworks have emulated that.

(Disclaimer: I work for the company which developed Django, and am an active user of and contributor to it)

Re:Patch details

[BlurredWeasel]

To let you know it is trivial to turn off the default mappings, they sit in routes.rb. It explicitly states in that file that it is a default mapping. Just get rid of the appropriate line, and you're good. You will have to add mappings yourself though to re-enable all your controllers.

Kids are so lazy those days...

[Anonymous Coward]

reviewing the diff between the versions, this is what I found:

1. a new test at rails/vendor/rails/activerecord/test/base_test.rb for SQL injections on ActiveRecord::Base.find

2. in the changelog for actionpack, we have:

* Added ActionController.filter_parameter_logging that makes it easy to remove passwords, credit card numbers, and other sensitive information from being logged when a request is handled. #1897 [jeremye@bsa.ca.gov]

So, I'd say the problem is on some of those.