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

41–50 of 66 posts

Re: Multiple security vulnerabilities in Rails

#41

Post by bobedybobbob »

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…

Do we really need CVE numbers assigned for all of these? More or less every application out there is vulnerable to some form of timing attack

Re: Multiple security vulnerabilities in Rails

#42

Post by eganist »

andersonmvd wrote: post #39
eganist wrote: post #36

Earlier quoted context omitted.

> [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 th…

Yup to all others you mentioned. I usually just teach about why trust matters and how to think about it as a developer. Works out well with training the devs at my current workplace. Back to your comments on the CVEs, the reason I replied the way I did was because your comments appeared to come across as being the only necessary mitigations per-se. I know that's not at all how you intended it ("some comments" as opposed to "how to mitigate"), but my first pass over the text made me feel that way about it.

In any case, nice chat. I like productive exchanges.

Re: Multiple security vulnerabilities in Rails

#43

Post by jmgao »

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…

You don't need to control every byte for this to be catastrophic. You can't decode every password like you can with the previous comparison, but if you can generate a rainbow table that contains the password you're trying to crack, you can just do a timing attack using the hashes instead. My intuition is that this might even require fewer attempts than the original comparison assuming a reasonable password length, but I haven't done the math.

Re: Multiple security vulnerabilities in Rails

#44

Post by bpchaps »

ryanlol wrote: post #22
enraged_camel wrote: post #21

Earlier quoted context omitted.

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

I don't understand comments like these.. He's pointing out a legitimate attitude problem which I, and many others, also agree with. There's absolutely no need for the flippant attitude.

If the users of your framework are consistently causing major security problems and the framework is built in a way that it can't be fixed without compromise.. I dunno.. document it? Maybe? Your documentation is basically the API to learning your framework, so if the API is broken to the extent of causing security problems, then it's not god damn production ready!

Remember, if every student is failing your class, the student probably isn't the one to blame.

Re: Multiple security vulnerabilities in Rails

#45

Post by trollian »

Nobody's actually still exposing rails sites to the internet are they? I mean except as a honeypot.

The rails team's approach to security (it's the application's problem) has been consistent. At this point if you're letting the wild Internet touch your rails apps it's probably your own fault.

Re: Multiple security vulnerabilities in Rails

#46

Post by josephagoss »

trollian wrote: post #45

Nobody's actually still exposing rails sites to the internet are they? I mean except as a honeypot. The rails team's approach to security (it's the application's problem) has been consistent. At this point if you're letting the wild Internet touch your rails apps it's probably your own fault.

Is this the general view? What is the best course of action here? Stop using Rails or somehow protect it better?

Re: Multiple security vulnerabilities in Rails

#47

Post by enraged_camel »

bpchaps wrote: post #44
ryanlol wrote: post #22

Earlier quoted context omitted.

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.

I don't understand comments like these.. He's pointing out a legitimate attitude problem which I, and many others, also agree with. There's absolutely no need for the flippant attitude. If the users of your framework are consistently causing major security problems and the framework is built in a way that it can't be fixed without compromise.. I dunno.. document it? Maybe? Your documentation is basically the API to l…

>>Remember, if every student is failing your class, the student probably isn't the one to blame.

Except not every student is failing the class. Only those not following best practices are.

For example, if you're using params.permit!, you're simply being lazy. This is clearly documented[1]:

"Extreme care should be taken when using permit! as it will allow all current and future model attributes to be mass-assigned."

[1]https://github.com/rails/strong_parameters#permitted-scalar-...

Re: Multiple security vulnerabilities in Rails

#48

Post by rimantas »

josephagoss wrote: post #46
trollian wrote: post #45

Nobody's actually still exposing rails sites to the internet are they? I mean except as a honeypot. The rails team's approach to security (it's the application's problem) has been consistent. At this point if you're letting the wild Internet touch your rails apps it's probably your own fault.

Is this the general view? What is the best course of action here? Stop using Rails or somehow protect it better?

The best course of action is to ignore trolls.

Re: Multiple security vulnerabilities in Rails

#49

Post by tomc1985 »

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…

As an everyday Rails user, most of these aren't really that surprising. Sure, one could cite 'defensive programming' or whatever, but a lot of these behaviors are warned against in the documentation.

Re: Multiple security vulnerabilities in Rails

#50

Post by phamilton »

toolz wrote: post #30
Someone1234 wrote: post #15

Earlier quoted context omitted.

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.

MINASWAN

https://en.wikipedia.org/wiki/MINASWAN

Post reply on HN