from Hacker News

Multiple security vulnerabilities in Rails

by alinajaf on 1/25/16, 8:51 PM with 62 comments

by andersonmvd on 1/25/16, 10:10 PM
I've grouped the patches for 4.1 and 4.2 here: https://drive.google.com/file/d/0BwnrE2iUdypUMkpqWVVPTXNzNVU... -- because download one by one is boring. Don't trust me, verify each file before patching. Some comments:
[CVE-2015-7581] Object leak vulnerability for wildcard controller routes in Action Pack: Look for routes that contain ":controller" and change it to something else. Hopefully you didn't have this weird name in your routes.
[CVE-2015-7578/79] Possible XSS vulnerability in rails-html-sanitizer: You're safe if you use a single page application that properly encode for you. Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good.
[CVE-2016-0753] Possible Input Validation Circumvention in Active Model: params.permit! is negligence, you should not be doing that anyway
[CVE-2016-0752] Possible Information Leak Vulnerability in Action View: render params[:id] is not defensive programming, so you should not be doing that too
[CVE-2015-7577] Nested attributes rejection proc bypass in Active Record: Only if using nested_attributes and rejection proc. Wasn't my case. Just patch.
[CVE-2016-0751] Possible Object Leak and Denial of Service attack in Action Pack: DoS is bad, just patch.
[CVE-2015-7576] Timing attack vulnerability in basic authentication in Action Controller: Just patch.
-- Doesn't look THAT bad, but need to be patched fast.
by nfm on 1/25/16, 10:10 PM
Doesn't look too bad, although there are a lot of CVEs to go through:
- A timing attack if you're using HTTP basic auth
- A couple of GC related DoS attacks
- An issue with `accepts_nested_attributes_for` if you're using both the `allow_destroy` and `reject_if` options
- A validation bypass exploit if you're calling `SomeModel.new(params[:some_model])` instead of using StrongParams
- An information leak exploit if you're calling `render params[:something]` with raw user input
- A bunch of potential XSS exploits
The `render` issue looks like it could cause the most harm, but hopefully shouldn't be too prevalent. The XSS issues should be a quick fix as you only have to update `rails-html-sanitizer`, not Rails itself.
by deanclatworthy on 1/25/16, 9:49 PM
I see a timing attack in the list. It's fairly trivial to mitigate against this in the majority of languages nowadays [1] [2] [3] etc..
I presume this can also be mitigated by implementing rate limiting on your authentication endpoints, although that should also be implemented for other reasons.
[1] https://golang.org/pkg/crypto/subtle/#ConstantTimeCompare
[2] http://php.net/manual/en/function.hash-equals.php
[3] http://www.levigross.com/2014/02/07/constant-time-comparison...
by matdrewin on 1/26/16, 1:46 AM
On one hand, I find that Rails often has security issues. On the other hand, perhaps it is just indicative of its popularity and interest. When a framework has no security issues, is it because there are none or is it just that no one can be bothered to look for some?
by dain on 1/26/16, 7:56 AM
Aah Aaron. Thanks. Everywhere he codes he refactors, fixes performance issues, finds bugs, he's so my hero.

by igravious on 1/26/16, 9:32 AM

A quick `bundle update` appears to be just the ticket:

    …
    Installing rails-html-sanitizer 1.0.3 (was 1.0.2)
    Installing actionmailer 4.2.5.1 (was 4.2.5)
    Installing activemodel 4.2.5.1 (was 4.2.5)
    Installing activerecord 4.2.5.1 (was 4.2.5)
    Installing railties 4.2.5.1 (was 4.2.5)
    Installing rails 4.2.5.1 (was 4.2.5)
    …
    Bundle updated!

by forced-request on 1/26/16, 3:46 PM
CVE-2016-0752 is explained in more detail here: https://nvisium.com/blog/2016/01/26/rails-dynamic-render-to-...
by tetraverse on 1/26/16, 12:24 PM
What was the name of that still-in-development OS that is going to mitigate against most forms of conventional attacks.
random quote: 'I used to consume cannabis on a daily basis, I suffer no short term memory loss, as far as I can remember....'