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

131–140 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#131

Post by nachteilig »

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…

This is actually the first I'm seeing about strong_parameters, since I don't follow Rails 4 stuff much right now. Thanks for the tip!

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#132

Post by rachelbythebay »

moe wrote: post #89

I hope in consequence of this incident the Rails-team will build in an automatic security-update notification mechanism. I'd like my apps to poll rails.org (or whatever) every few minutes and by default shutdown hard when an incident like this is announced.

That should be pretty easy to scale up. The past couple of weeks have established a decent precedent. Just have an endpoint called vuln_present or similar.

"return true;"

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#133

Post by nateberkopec »

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?

The number of security patches to a popular open source project has only a very weak correlation to the actual number of security holes.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#134

Post by jrochkind1 »

clickonchris wrote: post #71

Upgrade instructions: update your Gemfile and set the version you want. In my case: gem 'rails', '3.2.10' locally, run 'bundle update rails' which will update your Gemfile.lock check-in and deploy your code. If you are using capistranso, the default 'deploy' task should handle everything for you. Otherwise, run 'bundle update rails' on your production server.

3.2.11 not 3.2.10.

Which is in fact why it's probably wiser to list `gem 'rails', '~> 3.2.10'` (or 3.2.0 or anything) instead, and then `bundle update rials` will update you to latest 3.2.x (but never 3.3.x), in this case 3.2.11, instead of only to the exact version you specified (3.2.10, incorrectly).

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#135

Post by [deleted] »

m0nastic wrote: post #42
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?

All software has bugs, and the subset of bugs which turn out to be security vulnerabilities is borderline asymptotic. That's not to say all frameworks are created equally secure, but the differences have more to do with the culture around the project than any technical decisions (minus some very specific language-related issues). Rails is a big, public project; with many years now of being used by a sizable number of…

[deleted]

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#136

Post by steveklabnik »

nachteilig wrote: post #131
steveklabnik wrote: post #50

Earlier quoted context omitted.

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

This is actually the first I'm seeing about strong_parameters, since I don't follow Rails 4 stuff much right now. Thanks for the tip!

Any time. Please let me know any issues/problems/thoughts you have with it.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#137

Post by charliesome »

xentronium wrote: post #124

http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this 1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML "1 --" It looks like string, but it's not. 1.9.3p327 :002 > Keyword.where(:id => id).first Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LI…

Posting the gory details this early on is not a nice thing to do. It's probably best to hold off for a while until everyone has had a reasonable chance to upgrade.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#138

Post by dasil003 »

benmmurphy wrote: post #73
phillmv wrote: post #35

Earlier quoted context omitted.

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…

I've worked with other vendors. The rails security team is the best I've worked with. The major positives: * Quick turn around. I have another vendor where it takes up to 3 months to get stuff fixed. :( * They give you a patch to review before releasing publicly. This is very important and gives researchers a chance to fix any problems with the patch. With another vendor their fix missed a really obvious attack vecto…

As an average joe web dev I also found the security team very easy to work with when I discovered a vulnerability. In that case I worked directly with them to create the patch that was released as Rails 2.3.5. It was something like 48 hours from the time I discovered it to the release.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#139

Post by sergiotapia »

robconery wrote: post #23
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?

All web frameworks have vulnerabilities - the key is how quickly the team responds. For that, I love Rails (and @tenderlove)

I agree completely, it's just that this error seems so obvious and dangerous that it's odd it hasn't been caught for over 7 years.

ps: I love Tekpub! Are there any plans for some new Rails videos? I purchased the Rails 3 series but it's a bit outdated, given how fast Rails moves. Would purchase a series on Rails 4 day-one. :)

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#140

Post by jgeralnik »

aaronblohowiak wrote: post #130
tptacek wrote: post #122

Earlier quoted context omitted.

The people saying that they have POC code for remote code exec aren't making it up.

If I implied that I doubted them, then I failed to communicate my point effectively -- I am very curious about how to turn a class allocate + instance_variable_set into remote code exec. I see how you can create the arel objects for sqli, but not arbitrary ruby.

If you wait a couple of weeks you are much more likely to get an answer. Since all rails apps were vulnerable, most people who know how to execute arbitrary code are keeping silent for now.
Post reply on HN