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

Multiple vulnerabilities in parameter parsing in Action Pack

groups.google.com

Post reply on HN
Print view View original

61–70 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#61

Post by nathan_f77 »

sergiotapia wrote: post #14

As a newcomer to the Rails ecosystem all these posts of vunlerabilities and open doors leaves a bad taste in my mouth. God know I love programming in Ruby now, but is Rails really that insecure?

Please know that Rails is definitely very secure, and it has gone through many years of testing and review. However, no framework is immune. We should be grateful that the bug was found, patched, and notified, instead of being silently exploited by some black-hat who discovered it first.

The following is speculation, but keep in mind that this bug may have been found because the Rails team has been looking for security holes similar to the exploit that was found a few days ago.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#62

Post by tptacek »

marshray wrote: post #56
judofyr wrote: post #22

Earlier quoted context omitted.

I think it's better to not discuss this openly for a few days. The exploit isn't obviously (as you've noticed) so hopefully users will be able to upgrade before the script kiddies discovers this.

In the meantime, can you confirm that the disabling of XML and YAML inputs fully mitigates the RCE as well as the SQLi?

The vectors for both are the same. The term "SQLI" here is very misleading.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#64

Post by halogen64 »

ghayes wrote: post #40
tenderlove wrote: post #16

I'm just commenting here so that people can have a central thread for love / hatred. ;-) But seriously. This is extremely critical, please upgrade!

As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…

> As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you asked for is what you get (this solves the primary issue with attr_accessible).

It does not solve the issue of javascript generated forms.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#65

Post by mikeycgto »

steveklabnik wrote: post #50
ghayes wrote: post #40

Earlier quoted context omitted.

As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…

> why isn't there more of a focus on security here? More compared to what, exactly? This vulnerability was responded to pretty damn quickly after it was reported, given that almost nobody is even paid to work on Rails. If you saw Aaron tweeting about "working over the weekend" a few days ago, well, now you know. That said, you mention attr_accessible in your post: that's gone as of the next release of Rails. Basicall…

If you've recently started a new Rails project (or are thinking about it), you should use strong_parameters right off the bat!

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#67

Post by davesims »

steveklabnik wrote: post #54
fwilhelm wrote: post #39

For those of you interested in more details about this bug: I've posted a first analysis at http://www.insinuator.net/2013/01/rails-yaml/

I don't think this is very responsible of you. You should post this, but you should really wait a week or so.

Agreed.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#68

Post by ghayes »

halogen64 wrote: post #64
ghayes wrote: post #40

Earlier quoted context omitted.

As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…

> As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you asked for is what you get (this solves the primary issue with attr_accessible). It does not solve the issue of javascript generated forms.

Sure, but as with all things, it could be turned off. The more I think about it, the more I like this idea. I may as well try it out and mock up a pull request.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#69

Post by blacktulip »

rschmitty wrote: post #45

Rails noob here... with this and the other vulnerability from a few days ago, do all you need to do is update your rails gem to become safe? Current version at time of my post is 3.2.11, if I'm using that am I safe or do I need to perform additional steps?

if you have any production using rails version < 3.2.11 then upgrade to 3.2.11. You should not have to do anything else than upgrading.
Post reply on HN