So I've applied the workaround, which is great, but how do I test that the workaround is indeed working? I realize that providing an in-depth answer is tantamount to publishing an exploit how-to, but some reasonable way to privately test this would be very useful. Maybe a "simple" URL tester hosted by a trusted Rails source (e.g. rubyonrails.org)? Ok, has the obvious issue of showing the world who they should target,…
Multiple vulnerabilities in parameter parsing in Action Pack
151–160 of 294 posts
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#152I'm just commenting here so that people can have a central thread for love / hatred. ;-) But seriously. This is extremely critical, please upgrade!
Getting continuous errors on deploy during the bundle stage like so: /usr/lib/ruby/1.9.1/rubygems/remote_fetcher.rb:215:in `fetch_http': bad response Not Found 404 (http://bb-m.rubygems.org/quick/Marshal.4.8/activesupport-3.2.11.gemspec.rz) Is this because rubygems.org is being nailed?
This is a mirror, so that's why it's probably out of date...can you try just production.cf.rubygems.org ? I have heard zero reports of downtime or other issues. :/
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#153if you are using extlib gem you may be vulnerable as well.
it has just been updated:
https://github.com/datamapper/extlib/commit/633974b2759d9b92...
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#154This hits one my basic complaints about Rails: it activates too many features _by default_. Even if your app does not parse XML params, the parser is active. I know its convenient, but hey - is this worth the price of exposing _everyone_?
That's not a fair critique here. The problem isn't that Rails exposes XML by default. Everyone knew it did, and just processing XML isn't the issue.
The problem is that the XML code used in the untrusted request path was also used by code that handled trusted messages elsewhere, and those trusted messages had requirements that weren't appropriate for request-path messages.
Because JSON is so much more popular than XML in Rails apps now, a reasonable workaround for this problem is to just turn off XML if you're not using it. More importantly, it's a workaround that (a) does more to reduce the attack surface given how XmlMini works, and (b) was a workaround that disclosed less of the vulnerability last week. But don't let that confuse you about the nature of this bug.
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#155I might be the last one on earth that still runs a Rails 1.1.x app. This time the ancient one dodged a bullet. "ah, actually 1.1.x isn't vulnerable. The issue first arrived in 2.0" - https://twitter.com/tenderlove/status/288777229276704768
we had some rails 1.x apps at work and we were happy.
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#156Earlier quoted context omitted.
> why isn't there more of a focus on security here? More compared to what, exactly? This vulnerability was responded to pretty damn quickly after it was reported, given that almost nobody is even paid to work on Rails. If you saw Aaron tweeting about "working over the weekend" a few days ago, well, now you know. That said, you mention attr_accessible in your post: that's gone as of the next release of Rails. Basicall…
If you've recently started a new Rails project (or are thinking about it), you should use strong_parameters right off the bat!
I'm not 100% positive, but I don't think strong_parameters would do anything to protect you here.
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#157Why doesn't Ruby (and Python and all other languages) have Perl's tainting built in and always running? I'm not advocating it as the only security mechanism, but rather as another barrier to be overcome just like address-space-randomisation, data-exection prevention and all the rest... (Haven't Google recently shared a valgrind-lite runtime bounds checker which is being incorporated into GCC etc? Might lead the way o…
MRI has tainting through SAFE, but its generally considered problematic and might give a false sense of security. MRI and Rubinius don't implement it.
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#158http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this 1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML "1 --" It looks like string, but it's not. 1.9.3p327 :002 > Keyword.where(:id => id).first Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LI…
Posting the gory details this early on is not a nice thing to do. It's probably best to hold off for a while until everyone has had a reasonable chance to upgrade.
Do you think not selling guns on an open market stops criminals from obtaining them as well?
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#159Github.com (built on Rails) is currently having issues. If I had a tin foil hat, I'd put it on. Hopefully their issues are not related to this vulnerability.
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#160http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this 1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML "1 --" It looks like string, but it's not. 1.9.3p327 :002 > Keyword.where(:id => id).first Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LI…
For all its reputation as overly strict and pedantic, one of the good things Java did was make sure that if something looked like a string it was going to be a string...