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

121–130 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#121

Post by steveklabnik »

pekk wrote: post #99
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!

Why is strong_parameters not the only way? Rails is pretty opinionated in many other respects...

The downside of 'don't break APIs for minor version changes' means that you can't break APIs until the major version changes. ;)

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#122

Post by tptacek »

aaronblohowiak wrote: post #120
tptacek wrote: post #17

Earlier quoted context omitted.

Calling YAML::load on attacker-controlled content in a Ruby app of any complexity is very bad news. As Ben and 'judofyr said: this is remote code execution.

Is this because Yaml doesn't whitelist the classes for the objects that may be instantiated? They are allocated and then instance_variable_set'd so I'd be Very interested to learn how this poses a risk.

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

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#123

Post by dsl »

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.

But thats not how the security community works. Once this was posted literally every security team jumped on writing a PoC exploit and distributing it to customers. There will be point and click modules in Metasploit, IMPACT, and CANVAS by the end of the week at latest.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#124

Post by xentronium »

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 -- LIMIT 1

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#125

Post by caseyf »

I was curious about why Rails parses YAML nested inside XML to begin with. Turns out it was put in way back when so that ActiveRecord's from_xml/to_xml work as expected when a model contains serialized (ie. yaml) attributes.

Patch/issue from the old Rails issue tracker:

http://web.archive.org/web/20071218105822/http://dev.rubyonr...

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#126

Post by djbender »

tenderlove wrote: post #112
outside1234 wrote: post #77

Earlier quoted context omitted.

Thank you for your fast hard work on this - this is what makes the Rails community so great and why I love it over the other options out there. I know this has to have been a stressful weekend. Is there a tip jar anywhere for beer money for the team that worked on this?

You'll have to ask @bitsweat. I only accept hugs. <3

hugs += 1

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#127

Post by zende »

tenderlove wrote: post #112
outside1234 wrote: post #77

Earlier quoted context omitted.

Thank you for your fast hard work on this - this is what makes the Rails community so great and why I love it over the other options out there. I know this has to have been a stressful weekend. Is there a tip jar anywhere for beer money for the team that worked on this?

You'll have to ask @bitsweat. I only accept hugs. <3

I'll throw in on Gittip: https://www.gittip.com/tenderlove/

Would also be happy to give you a hug ;-)

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#128

Post by steveklabnik »

dsl wrote: post #123
steveklabnik wrote: post #54

Earlier quoted context omitted.

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

But thats not how the security community works. Once this was posted literally every security team jumped on writing a PoC exploit and distributing it to customers. There will be point and click modules in Metasploit, IMPACT, and CANVAS by the end of the week at latest.

> by the end of the week at latest.

This is the key bit for me: Rubygems is literally straining with everyone being frantic to upgrade. Giving it a few days means that everyone can patch their apps.

I don't believe that everyone will listen to little old me, of course, but that doesn't mean I can't tell them I don't think it's a not-great thing to do.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#130

Post by aaronblohowiak »

tptacek wrote: post #122
aaronblohowiak wrote: post #120

Earlier quoted context omitted.

Is this because Yaml doesn't whitelist the classes for the objects that may be instantiated? They are allocated and then instance_variable_set'd so I'd be Very interested to learn how this poses a risk.

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.
Post reply on HN