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

161–170 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#161

Post by alexanderh »

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…

>why isn't there more of a focus on security here?

Because this is ruby we're talking about. A "Fun" language that has 100000 ways todo the same thing, so newbs find it fun and easy. You can almost guess how the language works and almost always be right. Thats cool, great for learning, makes you feel like a superstar when you're just getting started with programming... but its really not such a good thing when it comes to maintainability, and security.

This breads a community of people who arent very mindful of anything but having fun coding. (not always a bad thing, but certainly not conducive to good security)

The second you talk about "Multi-platform" or "security" to your average ruby user, their eyes glaze over. They just want to make cool stuff on their Mac, not worry about Security and best practices.

You could say the same thing about a lot of interpreted languages, but Ruby is especially bad.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#162

Post by xnxn »

moe wrote: post #110
xnxn wrote: post #108

Earlier quoted context omitted.

Headline of the future: > Tens of Thousands of Rails Applications Remotely Disabled Following Rails.org Intrusion

Yes, that is to be expected - and absolutely worth it. The aftermath of an incident like the current one is a lot more expensive than an unplanned downtime.

Just playing devil's advocate here: a truly evil attacker could use the access logs from all the apps phoning home to build a list of vulnerable targets! :)

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#163

Post by teyc »

makomk wrote: post #160
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…

For all its reputation as overly strict and pedantic, one of the good things Java did was make sure that if something looked like a string it was going to be a string...

I just read this today and it is clever and horrific at the same time: http://websec.wordpress.com/2012/01/04/multiple-vulnerabilit...

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#165

Post by steveklabnik »

joevandyk wrote: post #156
mikeycgto wrote: post #65

Earlier quoted context omitted.

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

I'm not 100% positive, but I don't think strong_parameters would do anything to protect you here.

It would not have helped with this vulnerability, no. But it is a better way of handling filtering appropriate parameters.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#166

Post by FooBarWidget »

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.

Author of the SQL injection exploit blog post last week. This vulnerability is definitely not out of proportion: it is extremely critical and can be exploited without any conditions. Everyone should immediately upgrade.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#168

Post by Turing_Machine »

alexanderh wrote: post #161
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? Because this is ruby we're talking about. A "Fun" language that has 100000 ways todo the same thing, so newbs find it fun and easy. You can almost guess how the language works and almost always be right. Thats cool, great for learning, makes you feel like a superstar when you're just getting started with programming... but its really not such a good thing when it com…

Yes, you're right. There have never been any security problems with "serious" "nonfun" languages like C, or Java, or the .NET stack. :-/

This has nothing to do with the Ruby language, by the way, any more than a hole in IIS is a problem with .NET.

If you're going to talk smack, at least learn what you're talking about.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#169

Post by jgeralnik »

amix wrote: post #167

I am shocked that it's considered a smart idea to make it possible to execute code from XML files (and that this is the default setting)!?

Of course it's not considered a smart idea. That's why this was fixed. It was a (critical) bug.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#170

Post by subsystem »

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…

I really hope this isn't the sentiment of the RoR community. There has to be a place for critique when it's warranted. At this scale it's not a joke any more, you ask for what you need and otherwise you do less.
Post reply on HN