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

201–210 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#201

Post by elliotanderson »

charliesome wrote: post #137
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.

At this stage with the vulnerability publicly and widely reported - demonstrating an attack vector that involves seemingly harmless code is perfectly acceptable. Not everyone understands the magic involved and it would be able to spot exploitable code.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#202

Post by charliesome »

elliotanderson wrote: post #201
charliesome wrote: post #137

Earlier quoted context omitted.

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.

At this stage with the vulnerability publicly and widely reported - demonstrating an attack vector that involves seemingly harmless code is perfectly acceptable. Not everyone understands the magic involved and it would be able to spot exploitable code.

A harmless payload can be absolutely trivially turned into a malicious payload.

I intend to share some details about this later on, but not so soon after the vulnerability is announced. There has to be a reasonable amount of time allowed for people to patch their servers.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#203

Post by sj26 »

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…

Cost/benefit.

There are always going to be security holes in anything we make. We can be a bank and focus two feet ahead on making sure everything is as secure as possible, or stay aware of security (and not do anything stupid) while moving fast enough that any flaws are irrelevant/fixed when exposed.

It also highly depends on how much risk you're willing to accept. For the average rails app, absolute security is not as important as moving fast. Be an adult and make adult decisions about your tools and processes to suit your circumstances.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#204

Post by mattbee »

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…

Hmm, looking around I am thinking that if you don't want random object instantiation, this monkey-patch:

  module YAML; @@tagged_classes.delete('tag:ruby.yaml.org,2002:object'); end
makes user-supplied YAML a lot less dangerous. I am going to poke this into a production application and see if anything breaks - it really really shouldn't

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#205

Post by marshray »

lgleason wrote: post #150
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…

+1 Steve Part of being a good developer is understanding your framework and making sure that your app has the level of security you need. The framework cannot protect you from everything. The team responded really quickly. Aaron is a really talented developer and a nice guy. We should all be thanking him. If you don't feel that enough emphasis is being put into security in rails beat away at it, find holes and then g…

http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulner...

Here are some good and experienced Rails developers who apparently had no idea that Rails would automagically suck in XML and YAML and turn it into symbols instead of strings.

Clearly they aren't the only ones who didn't "understand the framework" or we wouldn't have gone a week with the impression that CVE-2012-5664 was only exploitable in specific circumstances.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#206

Post by steveklabnik »

marshray wrote: post #189
steveklabnik wrote: post #115

Earlier quoted context omitted.

But it was not knowledge to the general public until today. That's what matters. Those people have POCs, but they're not spreading them.

One should never assume that he has a handle on everyone who knows the existence of a bug. I think you underestimate your adversary. https://twitter.com/mikko/status/288766998228393984

You completely mis-understand my point. I don't think that this is the only person who knows this, that'd be idiotic. They are, however, the only person who posted it in this thread. Giving it more publicity. I don't think that that extra publicity is appropriate.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#208

Post by marshray »

Turing_Machine wrote: post #168
alexanderh wrote: post #161

Earlier quoted context omitted.

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

Hey, did you hear that scanf() will accept XML and YAML and automatically convert it into pointers handy for you to dereference?

Neither did I.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#209

Post by tptacek »

marshray wrote: post #208
Turing_Machine wrote: post #168

Earlier quoted context omitted.

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.

Hey, did you hear that scanf() will accept XML and YAML and automatically convert it into pointers handy for you to dereference? Neither did I.

Or how about when you put that 256th character in a ruby string and end up overwriting heap metadata? Man I hate it when that happens.
Post reply on HN