Multiple security vulnerabilities in Rails • Hacker News Board

Re: Multiple security vulnerabilities in Rails

#11

Post by matthewmacleod » Mon, Jan 25, 2016, 10:52 PM UTC

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…

Calm down a bit! The implication I take from the person you are responding to is not that the vulnerabilities don't matter, but that it's useful to reflect on them and make sure that you are always programming defensively.

Re: Multiple security vulnerabilities in Rails

#12

Post by semiquaver » Mon, Jan 25, 2016, 10:56 PM UTC

ryanlol wrote: post #9

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.

The vast majority of rails applications do not use HTTP basic authentication, and I would guess that most of the ones that do use nginx or apache to provide it. This was probably not caught until now because hardly anyone uses it.

Re: Multiple security vulnerabilities in Rails

#13

Post by ryanlol » Mon, Jan 25, 2016, 10:56 PM UTC

semiquaver wrote: post #12

ryanlol wrote: post #9

Earlier quoted context omitted.

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

The vast majority of rails applications do not use HTTP basic authentication, and I would guess that most of the ones that do use nginx or apache to provide it. This was probably not caught until now because hardly anyone uses it.

I've seen a bunch of companies use rails HTTP basic auth internally.

And it's not that it wasn't caught until now, it's that it wasn't caught before the commit was accepted.

Re: Multiple security vulnerabilities in Rails

#14

Post by eropple » Mon, Jan 25, 2016, 10:57 PM UTC

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…

I have a much bigger problem with your post than his--and calling him out for a "terrible attitude" regarding security is a little bit funny seeing as he runs Gauntlet.io, which while not my favorite scanner out there is a legit tool that deserves more respect than you have afforded him. He has his bona fides; where are yours?

And, more concretely, I have no problem with his pointing out that some of--not all, but some--these issues are ones mitigated by decent, security-aware software development practices, like, oh, "don't spit something into a template out of your input parameters". Because tools break. Your libraries break. They will always break. Program defensively in all situations where hostile input is possible and never take for granted any attempts to defuse attacks; always favor braces-and-belt wherever possible and you'll generally do okay. It's entirely unnecessary to be a jerk towards him for saying this.

Re: Multiple security vulnerabilities in Rails

#15

Post by Someone1234 » Mon, Jan 25, 2016, 11:05 PM UTC

matthewmacleod wrote: post #11

Someone1234 wrote: post #8

Earlier quoted context omitted.

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…

Calm down a bit! The implication I take from the person you are responding to is not that the vulnerabilities don't matter, but that it's useful to reflect on them and make sure that you are always programming defensively.

They went through most of the issues and shifted blame for the issue from Rails to the developer/user.

"Hopefully you didn't have this weird name in your routes."

"Stripping tags isn't the best way anyway to filter XSS, so if you're encoding, you're good."

"is negligence, you should not be doing that anyway"

"is not defensive programming, so you should not be doing that too"

It isn't "reflecting" it is blame shifting. And there's a huge difference between defensive programming and being psychic, in this case it is more the latter, as even features like the sanitiser we should have known better than to use as the docs tell us to.

Re: Multiple security vulnerabilities in Rails

#16

Post by koolba » Mon, Jan 25, 2016, 11:05 PM UTC

thibaut_barrere wrote: post #4

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

That's still broken. They've just pushed the problem deeper. Now instead of having a timing attack on the number of operations in the compare, the timing attack is pushed to the number of bytes that is hashed by sha256. Also, this opens up a new avenue in that now hash collisions (as unlikely as they may be) would be considered equal.

Re: Multiple security vulnerabilities in Rails

#17

Post by ryanlol » Mon, Jan 25, 2016, 11:12 PM UTC

koolba wrote: post #16

thibaut_barrere wrote: post #4

Earlier quoted context omitted.

The current implementation is here: https://github.com/rails/rails/commit/859ca4474e1608b83d6194...

That's still broken. They've just pushed the problem deeper. Now instead of having a timing attack on the number of operations in the compare, the timing attack is pushed to the number of bytes that is hashed by sha256. Also, this opens up a new avenue in that now hash collisions (as unlikely as they may be) would be considered equal.

>Also, this opens up a new avenue in that now hash collisions (as unlikely as they may be) would be considered equal.

Hash collision implies attacker has control of both the inputs, in this case we'd be talking about a preimage attack.

If your attacker can perform preimage attacks on SHA256 they can also most likely hack you via your package manager.

Re: Multiple security vulnerabilities in Rails

#18

Post by matthewcford » Mon, Jan 25, 2016, 11:12 PM UTC

semiquaver wrote: post #12

ryanlol wrote: post #9

Earlier quoted context omitted.

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

The vast majority of rails applications do not use HTTP basic authentication, and I would guess that most of the ones that do use nginx or apache to provide it. This was probably not caught until now because hardly anyone uses it.

I imagine every app on Heroku which uses basic auth is at risk then.

Re: Multiple security vulnerabilities in Rails

#19

Post by Someone1234 » Mon, Jan 25, 2016, 11:13 PM UTC

eropple wrote: post #14

Someone1234 wrote: post #8

Earlier quoted context omitted.

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…

I have a much bigger problem with your post than his--and calling him out for a "terrible attitude" regarding security is a little bit funny seeing as he runs Gauntlet.io, which while not my favorite scanner out there is a legit tool that deserves more respect than you have afforded him. He has his bona fides; where are yours? And, more concretely, I have no problem with his pointing out that some of--not all, but so…

> He has his bona fides; where are yours?

I called him out for his specific replies in this specific thread. I didn't call out his reputation or character.

Maybe you should stick to what they and I actually posted here today, and not try to draw the conversation off track into reputation wars.

> It's entirely unnecessary to be a jerk towards him for saying this.

I don't appreciate being called a "jerk."

I stand by what I said, and what I said was that I felt (and feel) that they have a bad attitude to security. They're trying to shift blame from the rails developers to every rails user, and their excuses are weak.

If you think that is "jerky," that's fine, but I feel like name calling and playing the reputation card for no reason is only going to take a conversation down a bad and unconstructive path.

Re: Multiple security vulnerabilities in Rails

#20

Post by ryanlol » Mon, Jan 25, 2016, 11:23 PM UTC

eropple wrote: post #14

Someone1234 wrote: post #8

Earlier quoted context omitted.

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…

I have a much bigger problem with your post than his--and calling him out for a "terrible attitude" regarding security is a little bit funny seeing as he runs Gauntlet.io, which while not my favorite scanner out there is a legit tool that deserves more respect than you have afforded him. He has his bona fides; where are yours? And, more concretely, I have no problem with his pointing out that some of--not all, but so…

I'm not sure how who he is or what he does is at all relevant here.

Especially considering that he makes pretty obvious factual errors, e.g:

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

If you don't want any HTML you aren't supposed to be using rails-html-sanitizer, it's specifically for scenarios where you can't do that.