5 ms·

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

34 points by rst 16y ago

jfirebaugh 16y ago
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_thread/thread/2d95a3cc23e03665 http://groups.google.com/group/rubyonrails-security/browse_t...
- nbpoole 16y ago
  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.
ncavig 16y ago
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.
tptacek 16y ago
* 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.
- ubernostrum 16y ago
  Yeah, the CSRF thing is very much not happy time.
- nbpoole 16y ago
  http://code.djangoproject.com/changeset/15464/django/trunk/django/middleware/csrf.py 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.
  - ubernostrum 16y ago
    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.
    - nbpoole 16y ago
      Fair enough. I guess I'll just have to work it out for myself. :P
      - tptacek 16y ago
        Sam Quigley says: http://twitter.com/emerose/status/35169573590409216 http://twitter.com/emerose/status/35169573590409216
        nbpoole 16y ago
        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.
        nbpoole 16y ago
        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.
- rst 16y ago
  The Django blog has a description of the CSRF problem here: http://www.djangoproject.com/weblog/2011/feb/08/security/ 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.
ubernostrum 16y ago
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 http://news.ycombinator.com/item?id=2196214
mcollina 16y ago
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-and-3-0-4 http://weblog.rubyonrails.org/2011/2/8/new-releases-2-3-11-a...

34 points by rst 16y ago

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_thread/thread/2d95a3cc23e03665 http://groups.google.com/group/rubyonrails-security/browse_t...

nbpoole 16y ago
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.

ncavig 16y ago

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.

tptacek 16y ago

* 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.

ubernostrum 16y ago
Yeah, the CSRF thing is very much not happy time.
nbpoole 16y ago
http://code.djangoproject.com/changeset/15464/django/trunk/django/middleware/csrf.py 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.
- ubernostrum 16y ago
  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.
  - nbpoole 16y ago
    Fair enough. I guess I'll just have to work it out for myself. :P
    - tptacek 16y ago
      Sam Quigley says: http://twitter.com/emerose/status/35169573590409216 http://twitter.com/emerose/status/35169573590409216
      - nbpoole 16y ago
        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.
      - nbpoole 16y ago
        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.
rst 16y ago
The Django blog has a description of the CSRF problem here: http://www.djangoproject.com/weblog/2011/feb/08/security/ 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.

ubernostrum 16y ago

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 http://news.ycombinator.com/item?id=2196214

mcollina 16y ago

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-and-3-0-4 http://weblog.rubyonrails.org/2011/2/8/new-releases-2-3-11-a...