Security patch releases to Rails 2.3.x, 3.0.x | Hacker News Reader

Security patch releases to Rails 2.3.x, 3.0.x

weblog.rubyonrails.org

34 pointsrst19 comments

* In mail_to :encode => :javascript, they weren't sanitizing email addresses, just catting them into the tag.

* There were using Enumerable#reject (ie, default allow) with a strict filter to decide which controllers/actions to route requests to, but case-insensitive filesystems aren't similarly strict.

* (Worst of all) ActiveRecord::QueryMethods#limit/limit_value wasn't sanitized while building queries (try Foo.limit("1,,0") for the flavor).

I don't know what the CSRF thing was either, but it looks like a headachey fix.

Yeah, the CSRF thing is very much not happy time.

http://code.djangoproject.com/changeset/15464/django/trunk/d...

Django released a similar fix. According to their changeset, we'll see a release from them shortly as well. Maybe they'll shed some more light on the issue.

Since I have the announcement right in front of me (I'm revising it in preparation for the final post), I can tell you there's not really any more detail in it than in the Rails post.

I don't know yet when the full full disclosure will happen; I just know that right now I'm really not at liberty to do that.

Fair enough. I guess I'll just have to work it out for myself. :P

Sam Quigley says:

http://twitter.com/emerose/status/35169573590409216

That's not it, unless I'm missing something big.

Flash and Java both disallow cross-domain requests unless specifically allowed by a crossdomain.xml file (or you use a DNS rebinding attack on Java). Furthermore, to the best of my knowledge, if you can make an HTTP request in Java or Flash you can read back the result.

To be perfectly clear, Sam is not wrong. Flash and Java both let you issue requests with that header. However, if you try and make a cross-origin request, they'll both throw exceptions unless you have permission (in the form of a crossdomain.xml file). I assume that's where the redirects come into play, although I can't imagine how you redirect someone's POST request to a different domain.

I'm just messing with you both.

Resetting sessions on CSRF failures is going to suck for us.

Is there any reason to reset the session on a CSRF failure vs. just failing the request? Seems like you could have fun DOSing people from their sessions on other sites with that default behavior.

That's right. Of course, without knowing more details about the vulnerability, it's hard to say whether there's a benefit to ending the session.

I don't have any inside information on this, but my guess is that this is going to come down to confusion about 302/303/307 redirects. In theory, clients receiving a 302 in response to a POST are supposed to re-send the POST wherever the redirect leads; in practice, clients do all kinds of different things. This feels like just the kind of weird edge case that defeats fragile security mechanisms like crossdomain.xml.

I probably shouldn't have phrased that so definitively: I don't have any evidence that Flash is to blame here. In fact, given that this problem required a framework-level fix (rather than, eg, a simple patch from Adobe) I suspect that this affects a lot of things.

In my tweet, I just meant to say that Rails checked for something very simple: a header that Flash's addRequestHeader() can trivially fake out. As Neal points out, that can't be the whole story — but I suspect it's part of it.

The Django blog has a description of the CSRF problem here: http://www.djangoproject.com/weblog/2011/feb/08/security/

Briefly, when both frameworks got an "X-Requested-With" header, they assumed that it was coming from a browser XmlHttpRequest, and that the same-origin policy was in effect. So, they skipped CSRF checks.

However, it turns out that there is a way (details still not disclosed, other than that plugins and redirects are involved) for an attacker to force arbitrary headers onto a web request. Ooops.

Both frameworks are now applying CSRF checks strictly, with no exceptions for apparent XHR.

I'm curious about the technical details of the CSRF bypass vulnerability. Anyone know what the "combinations of browser plugins and HTTP redirects" that lead to it are?

http://groups.google.com/group/rubyonrails-security/browse_t...

Same here. Based on the changes made in the patch, it seems like the attack involves being able to make cross-domain requests but not being able to read back the response. I didn't think that was the way Java and Flash behaved.

run 'bundle update rails' instead of 'bundle update'. If you're like me, you'd like to only update the rails gem.

EDIT: If you run bundle update with no parameters, bundler will ignore any previously installed gems and resolve all dependencies again based on the latest versions of all gems available in the sources.

These versions are NOT ONLY a security fix, they might contains some bugs. Fully test your applications before going to production. See comments on: http://weblog.rubyonrails.org/2011/2/8/new-releases-2-3-11-a...

Cross-posting my comment from the Django thread, for those of you wondering whether anyone else was affected:

http://news.ycombinator.com/item?id=2196214

Reply on news.ycombinator.com