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

21–30 of 66 posts

Re: Multiple security vulnerabilities in Rails

#21

Post by enraged_camel »

Someone1234 wrote: post #19
eropple wrote: post #14

Earlier quoted context omitted.

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

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

Then try not to sound like one? The OP went out of his way to compile and document the important bugs and post them here. You, on the other hand, completely ignored the value of his contribution and instead rudely called him out on a very minor (and frankly, subjective) tonal issue, and went so far as to call it "whitewashing," which implies that he has an agenda.

Re: Multiple security vulnerabilities in Rails

#22

Post by ryanlol »

enraged_camel wrote: post #21
Someone1234 wrote: post #19

Earlier quoted context omitted.

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

>>I don't appreciate being called a "jerk Then try not to sound like one? The OP went out of his way to compile and document the important bugs and post them here. You, on the other hand, completely ignored the value of his contribution and instead rudely called him out on a very minor (and frankly, subjective) tonal issue, and went so far as to call it "whitewashing," which implies that he has an agenda.

Did you not notice how OP had absolutely nothing to say about the more serious bugs and instead entirely focused on the less serious ones? (Except for the rails-html-sanitizer bug, which is fairly serious)

He does make multiple valid points though.

Re: Multiple security vulnerabilities in Rails

#23

Post by zaroth »

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.

This is considered best practice for languages where you can't trust your "constant time" comparison won't be optimized out from under you.

Performing a timing attack requires control of the bytes being compared. If you can control the bytes of the output of a SHA256 then there are some Bitcoin miners who will pay you a lot of money.

If you want to be over-the-top about it you can get some secure randomness and add it to the values being compared before hashing, and then attacker would have even less control over the bytes being compared.

Re: Multiple security vulnerabilities in Rails

#24

Post by andersonmvd »

ryanlol wrote: post #20
eropple wrote: post #14

Earlier quoted context omitted.

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

True, but there are better alternatives in some situations, e.g., bbcode or markdown processing rather than stripping tags. The point for such scenarios is that whitelist is better than blacklist.

Re: Multiple security vulnerabilities in Rails

#25

Post by ryanlol »

zaroth wrote: post #23
koolba wrote: post #16

Earlier quoted context omitted.

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.

This is considered best practice for languages where you can't trust your "constant time" comparison won't be optimized out from under you. Performing a timing attack requires control of the bytes being compared. If you can control the bytes of the output of a SHA256 then there are some Bitcoin miners who will pay you a lot of money. If you want to be over-the-top about it you can get some secure randomness and add i…

I suppose you could theoretically deduce a large enough part of the hash to perform a bruteforce attack though.

You don't need that much of the hash to perform wordlist attacks and find likely candidates.

Re: Multiple security vulnerabilities in Rails

#26

Post by rst »

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…

More like "avoid these particular, obviously risky constructs, which any good security scanner will call out as high-priority trouble spots". The two particular constructs he warns against ("render params" and permit! followed by mass assignment) will both get high-priority warnings from Brakeman.

Re: Multiple security vulnerabilities in Rails

#27

Post by ryanlol »

andersonmvd wrote: post #24
ryanlol wrote: post #20

Earlier quoted context omitted.

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

True, but there are better alternatives in some situations, e.g., bbcode or markdown processing rather than stripping tags. The point for such scenarios is that whitelist is better than blacklist.

Absolutely, bbcode and markdown processing are significantly better alternatives.

Also, I'm pretty sure you're specifically supposed to use rails-html-sanitizer with a whitelist. (See: Rails::Html::WhiteListSanitizer)

Re: Multiple security vulnerabilities in Rails

#28

Post by eropple »

ryanlol wrote: post #13
semiquaver wrote: post #12

Earlier quoted context omitted.

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.

I expect (though I have not looked) that it's old code that wasn't eyeballed for security so much as for consistency and correctness. Once in, it doesn't leave.

Re: Multiple security vulnerabilities in Rails

#29

Post by dsp1234 »

andersonmvd wrote: post #24
ryanlol wrote: post #20

Earlier quoted context omitted.

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

True, but there are better alternatives in some situations, e.g., bbcode or markdown processing rather than stripping tags. The point for such scenarios is that whitelist is better than blacklist.

The point for such scenarios is that whitelist is better than blacklist.

from CVE-2015-7580:

Carefully crafted strings can cause user input to bypass the sanitization in the white list sanitizer

So people are using a whitelist, and this bug is in that whitelist. In other words, people are "doing the right thing" and are still vulnerable.

Re: Multiple security vulnerabilities in Rails

#30

Post by toolz »

Someone1234 wrote: post #15
matthewmacleod wrote: post #11

Earlier quoted context omitted.

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…

Stop making this about ego. The person was helping developers secure their apps and you're trying to make this about who is wrong. Making sure someone feels bad in the open source community won't make anything better.
Post reply on HN