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

31–40 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#33

Post by danso »

diminish wrote: post #25
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!

3 links on HN frontpage for this same vulnerability proves the love of the community to warn each other tenderly.

There's actually two vulnerability announcements: https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...

This one deals with problematic JSON parsing and affects only 3.x. It is dealt with in the release that fixes the other vulnerability

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#34

Post by sdoowpilihp »

Can anyone with a more intimate knowledge of the inner workings of Ruby on Rails speak to how detrimental this exploit is in practice? I seem to recall a fair number of people feeling the SQL injection exploit from a few days ago was being blown out of proportion and I was wondering how this particular exploit stacks up against it.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#35

Post by phillmv »

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?

Security is a process; what matters is how people respond to new vulnerabilities. I'm naturally biased pro-Rails, but so far I don't feel uncomfortable with how it has been handled.

I can't comment on how on-the-ball the Rails security team is, but I can say it's really easy to update your apps.

It's also relative to your alternatives. It's way safer than not using a framework. Is it safer than Django? That's kind of unknowable; maybe, maybe not.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#37

Post by tptacek »

sdoowpilihp wrote: post #34

Can anyone with a more intimate knowledge of the inner workings of Ruby on Rails speak to how detrimental this exploit is in practice? I seem to recall a fair number of people feeling the SQL injection exploit from a few days ago was being blown out of proportion and I was wondering how this particular exploit stacks up against it.

This one is not blown out of proportion. Lots of people have working proof-of-concept exploits for this. The vulnerability has no app dependencies. You don't need a session secret. You don't need a login. There are vectors for the vulnerability that will work against applications that don't even have exposed controllers.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#38

Post by viseztrance »

I really don't understand the last part "This vulnerability was reported to us by numerous people, many thanks to [...]".

Considering it affects all versions, what are the odds of multiple people pointing this out at the same time?

Rails has a very good track record regarding these things, but I'm just curious.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#40

Post by ghayes »

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 asked for is what you get (this solves the primary issue with attr_accessible). I feel getting this right is crucial to Rails' future.

Post reply on HN