Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MultiXml gem has same vulnerability as Rails' CVE-2013-0156 – patch now

gist.github.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: MultiXml gem has same vulnerability as Rails' CVE-2013-0156 – patch now

#21

Post by fowlduck »

jrochkind1 wrote: post #16

Hmm, I'm not sure you could say it has "the same vulnerability". It has the same vulnerability if you pass untrusted input to it, okay. But the point of the Rails vulnerabilty is that every Rails app, by default, was set up to accept external user input and run it through an XML parser. Even if you didn't realize it. If you are using MultiXml, you may or may not be passing untrusted user input to it, depends on what…

It is the same vulnerability at a fundamental level (it's virtually the same code), but it isn't exploitable out of the box in the same way Rails was, at least not on its own. However, there is a web framework, Grape, that was exploitable in exactly the same way that Rails was due to MultiXml's vulnerability.

And, really, technically, it was ActiveSupport that had this vulnerability. Even outside of Rails, had you used Hash.from_xml on untrusted user input you would have run into exactly the same issues.

Re: MultiXml gem has same vulnerability as Rails' CVE-2013-0156 – patch now

#22

Post by sferik »

bradleybuda wrote: post #12
nelhage wrote: post #7

I strongly recommend loading something like this in your Ruby applications: https://gist.github.com/4507129 It will prevent YAML.rb from instantiating arbitrary objects, which will close off this entire class of problems. Obviously, if you do use YAML as a serialization format for arbitrary objects, this won't work, but odds are you aren't doing that.

Unfortunately, it doesn't look like this patch works in Ruby 1.9, where YAML is actually the Psych module. Any Psych experts know how to make this 1.9-compatible?

YAML is aliased to Psych:

irb(main):001:0> require 'yaml'

=> true

irb(main):002:0> YAML

=> Psych

Re: MultiXml gem has same vulnerability as Rails' CVE-2013-0156 – patch now

#23

Post by thibaut_barrere »

bradleybuda wrote: post #12
nelhage wrote: post #7

I strongly recommend loading something like this in your Ruby applications: https://gist.github.com/4507129 It will prevent YAML.rb from instantiating arbitrary objects, which will close off this entire class of problems. Obviously, if you do use YAML as a serialization format for arbitrary objects, this won't work, but odds are you aren't doing that.

Unfortunately, it doesn't look like this patch works in Ruby 1.9, where YAML is actually the Psych module. Any Psych experts know how to make this 1.9-compatible?

It doesn't work for me either on 1.9 - anyone with an explanation?

I commented here:

https://gist.github.com/4507129

Re: MultiXml gem has same vulnerability as Rails' CVE-2013-0156 – patch now

#24

Post by sferik »

thibaut_barrere wrote: post #23
bradleybuda wrote: post #12

Earlier quoted context omitted.

Unfortunately, it doesn't look like this patch works in Ruby 1.9, where YAML is actually the Psych module. Any Psych experts know how to make this 1.9-compatible?

It doesn't work for me either on 1.9 - anyone with an explanation? I commented here: https://gist.github.com/4507129

The patch I applied does not use YAML.tagged_classes.

Re: MultiXml gem has same vulnerability as Rails' CVE-2013-0156 – patch now

#25

Post by jmileham »

jrochkind1 wrote: post #16

Hmm, I'm not sure you could say it has "the same vulnerability". It has the same vulnerability if you pass untrusted input to it, okay. But the point of the Rails vulnerabilty is that every Rails app, by default, was set up to accept external user input and run it through an XML parser. Even if you didn't realize it. If you are using MultiXml, you may or may not be passing untrusted user input to it, depends on what…

If you're consuming even one third-party XML API using multi_xml, that means you're open to RCE if that API provider is malicious or itself compromised, as well as man in the middle attacks if you're not consuming the API via SSL.

Harder to exploit, perhaps, but given the large number of Rails apps that themselves are likely to be unpatched right now, pivoting to RCE on every customer of a SaaS provider seems like a very viable attack vector. Strongly recommend that everybody look at this seriously.

Post reply on HN