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

31–40 of 66 posts

Re: Multiple security vulnerabilities in Rails

#31

Post by Alex3917 »

andersonmvd wrote: post #10
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…

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

I mean ideally you should 1) strip tags 2) encode 3) use X-XSS headers 4) use CSP headers. That way if any one of these fails, the others will catch it.

That said, there still shouldn't be security holes in the framework.

Re: Multiple security vulnerabilities in Rails

#32

Post by warfangle »

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…

But Rails Culture is to make developers smile!

Fixing security vulnerabilities and writing docs that actually reflect best security practices do not make developers smile.

And accusing to have a terrible attitude does not make a developer smile either, so this is obviously your fault!

/s

Re: Multiple security vulnerabilities in Rails

#33

Post by zaroth »

ryanlol wrote: post #25
zaroth wrote: post #23

Earlier quoted context omitted.

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.

Yes, this is true if you are talking about unsalted passwords, or if the attacker knows the salts. If there's an unknown salt, having the salted hash of a given plaintext input match the first few bytes of the target salted hash does not help you narrow the word list at all. If there is no salt, or the salt is public, then that's a case where you could append some ephemeral CS-PRNG output to both sides before hash-comparing... but probably better to fix the underlying issue.

I mean, it's funny to be far enough down the rabbit hole to be doing hash-compare. Then to say we wanted randomly keyed hash-compare is the final step. The nice thing is adding some random bytes imposes a fairly miniscule performance hit and it's purely computation, no additional storage. Probably still too slow to use for every comparison, but for constant-time critical comparison, it literally can't hurt.

Re: Multiple security vulnerabilities in Rails

#34

Post by andersonmvd »

Alex3917 wrote: post #31
andersonmvd wrote: post #10

Earlier quoted context omitted.

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

I mean ideally you should 1) strip tags 2) encode 3) use X-XSS headers 4) use CSP headers. That way if any one of these fails, the others will catch it. That said, there still shouldn't be security holes in the framework.

Well said, I agree.

Re: Multiple security vulnerabilities in Rails

#35

Post by makomk »

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.

BBcode can go pretty horrifically wrong from a security perspective because you're still generating HTML markup based on unstructured, untrusted user input. There's a long and nasty history of XSS issues in forums that use BBcode where clever use of mismatched markup has made it possible to break the HTML generator enough to inject JavaScript and other nasties.

Re: Multiple security vulnerabilities in Rails

#36

Post by eganist »

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…

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

So uh, what if your application is taking an input that's then parsed by another application with poor output encoding? Granted, the application that's properly encoding for the correct context is good, but any applications which don't do that but also use that same dataset are screwed because your application didn't perform proper input validation.

Defense in depth strategies exist for a reason. Input validation, output encoding for every single context (this includes using angular properly, for instance), anti-xss headers, CSP, the list goes on. These aren't all prescribed just to protect that one application. They're prescribed so that when applied correctly across all apps, they're all protected from negligence in one app harming the data.

Re: Multiple security vulnerabilities in Rails

#37

Post by matdrewin »

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?

Re: Multiple security vulnerabilities in Rails

#38

Post by brazzledazzle »

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 called him out for his specific replies in this specific thread. I didn't call out his reputation or character.

Eh, I'm not sure about that. When I see "Wow you have a terrible attitude about security" I'm inclined to think that's exactly what you're doing. I don't have a horse in this race but you seem to be unnecessarily aggressive/antagonistic and you could have discussed the individual merits of his comment without doing that.

Re: Multiple security vulnerabilities in Rails

#39

Post by andersonmvd »

eganist wrote: post #36
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…

> [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. So uh, what if your application is taking an input that's then parsed by another application with poor output encoding? Granted, the application that's properly encoding for th…

Indeed, "any applications which don't do that but also use that same dataset are screwed". You're totally right. I didn't specify whether the encoded string is persisted or not. You considered that it isn't, which leads to the application with poor controls that you mentioned. Nice point. You're also right about defense in depth. I just wanted to highlight when an approach can be dangerous. That's one example, but there are others such as misuse of eval, constantize, etc. If the developer be aware of such risks and implement properly, even some (not all of course) newly disclosed vulnerabilities won't affect the application.

Re: Multiple security vulnerabilities in Rails

#40

Post by elliotec »

matdrewin wrote: post #37

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?

Excellent point. Also the fact is there will be people working on these immediately.
Post reply on HN