Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiple security vulnerabilities in Rails

groups.google.com

Post reply on HN
Print view View original

1–10 of 66 posts

Re: Multiple security vulnerabilities in Rails

#3

Post by deanclatworthy »

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

Re: Multiple security vulnerabilities in Rails

#4

Post by thibaut_barrere »

deanclatworthy wrote: post #3

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] htt…

The current implementation is here:

https://github.com/rails/rails/commit/859ca4474e1608b83d6194...

Re: Multiple security vulnerabilities in Rails

#5

Post by nfm »

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.

Re: Multiple security vulnerabilities in Rails

#6

Post by andersonmvd »

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.

Re: Multiple security vulnerabilities in Rails

#8

Post by Someone1234 »

andersonmvd wrote: post #6

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…

Wow you have a terrible attitude about security. "None of these are an issue, just program in this [very specific way that requires pre-knowledge of these vulnerabilities] and you're safe, anything else is basically negligence."

Your opinions about rails-html-sanitizer are particularly troubling as even if you use the sanitizer as suggested in the docs you're vulnerable and your retort is "well you should encode AND sanitise, not just rely on the sanitiser doing what the documentation says it should do!" Why?

I have no issue with the wording in the official CVEs. But this attempt at whitewashing the, frankly, pretty serious issues is deplorable.

Re: Multiple security vulnerabilities in Rails

#9

Post by ryanlol »

nfm wrote: post #5

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 yo…

>- A timing attack if you're using HTTP basic auth

I'd say that qualifies as pretty bad.

How the hell does that even happen? Using time constant string comparison is authentication 101. That's really not something you can mess up by mistake, it's something you mess up by not understanding what you're doing. And that's is all ignoring the fact that there's no reason to not use hashing here.

Re: Multiple security vulnerabilities in Rails

#10

Post by andersonmvd »

Someone1234 wrote: post #8
andersonmvd wrote: post #6

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…

Wow you have a terrible attitude about security. "None of these are an issue, just program in this [very specific way that requires pre-knowledge of these vulnerabilities] and you're safe, anything else is basically negligence." Your opinions about rails-html-sanitizer are particularly troubling as even if you use the sanitizer as suggested in the docs you're vulnerable and your retort is "well you should encode AND…

Some programming styles are not defensive from a security perspective. As a programmer one should acknowledge that using "render" passing a param right from the request, without validating it, is not a good thing, right? That's my point. Some issues here can be solved just by taking the right approach, but won't solve for all of them, of course. XSS mitigation works better with encoding rather than sanitization. If you want me to explain I explain.

But hey, you won't do any good complaining in face of this situation. Time to help people fix it. Peace.

Post reply on HN