Hacker News new | past | comments | ask | show | jobs | submit login
MultiXml gem has same vulnerability as Rails' CVE-2013-0156 – patch now (gist.github.com)
44 points by fowlduck on Jan 10, 2013 | hide | past | web | favorite | 25 comments

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 you did with it.


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.

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.

That's correct. But I'm planning to remove this functionality anyway, just to be safe. It's too easy to accidentally open this vulnerability and it's unclear what the valid use-case is for parsing YAML or symbols from XML.

When I implemented this functionality, it was only to be compatible with the Rails parser.

Yo dawgs, the mailchimp, aws-sdk, jenkins and twilio gems use HTTParty which uses multi_xml. You should look into this.

I appreciate this comment more than I have words. Dawg.

Actually paperclip doesn't rely on HTTParty, but def check out your Gemfile.lock anyway -- it's a pretty common library dependency.

    > Actually paperclip doesn't rely on HTTParty
I thought it uses aws-sdk? Looks like it doesn't. Huh..


It's like ActiveRecord, where it comes with an adapter for several backends, but in order to use a backend you need to install a library gem which is not a dependency of ActiveRecord.

Quick clarification: The multi_xml gem has _not_ been updated, so there is nothing to upgrade, correct? Just the monkey-patch fix?

Oh hmm, I guess that's a good thing to point out. Yes, the multi_xml gem has not been upgraded, and the listed dependencies for httparty and mailchimp haven't changed either.

A new gem release is in the works and should be pushed tomorrow. In the mean time, you can use this workaround.

MultiXML version 0.5.2 is now released.

Or reference HTTParty from git, which has been fixed, in your Gemfile:


Correction: Although this might not have much to do with multi_xml if that security risk isn't mitigated.

YAML can still be loaded from XML response bodies, it just doesn't parse response bodies that are pure YAML anymore. Something like <tag type="yaml">yaml here</tag>.

Though the 'twilio' gem does use HTTParty, 'twilio-ruby' doesn't. So just make sure to check your Gemspec.lock.

Also bugsnag.

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:


The patch I applied does not use YAML.tagged_classes.

YAML is aliased to Psych:

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

=> true

irb(main):002:0> YAML

=> Psych

A version of multi_xml with this fix has been pushed:


I'm keeping track of a list of vulnerable gems here: https://gist.github.com/4532291

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact