5 ms·

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

44 points by fowlduck 14y ago

jrochkind1 14y ago
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. Right?
- sferik 14y ago
  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.
- fowlduck 14y ago
  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.
- jmileham 14y ago
  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.
kanzure 14y ago
Yo dawgs, the mailchimp, aws-sdk, jenkins and twilio gems use HTTParty which uses multi_xml. You should look into this.
- cdcarter 14y ago
  Though the 'twilio' gem does use HTTParty, 'twilio-ruby' doesn't. So just make sure to check your Gemspec.lock.
- bradly 14y ago
  Quick clarification: The multi_xml gem has _not_ been updated, so there is nothing to upgrade, correct? Just the monkey-patch fix?
  - kanzure 14y ago
    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.
  - sferik 14y ago
    A new gem release is in the works and should be pushed tomorrow. In the mean time, you can use this workaround.
  - sferik 14y ago
    MultiXML version 0.5.2 is now released.
- FuzzyDunlop 14y ago
  Or reference HTTParty from git, which has been fixed, in your Gemfile: https://github.com/jnunemaker/httparty/commit/53a812426dd32108d6cba4272b493aa03bc8c031 https://github.com/jnunemaker/httparty/commit/53a812426dd321... Correction: Although this might not have much to do with multi_xml if that security risk isn't mitigated.
  - fowlduck 14y ago
nelhage 14y ago
I strongly recommend loading something like this in your Ruby applications: https://gist.github.com/4507129 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.
- bradleybuda 14y ago
  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?
  - sferik 14y ago
    YAML is aliased to Psych: irb(main):001:0> require 'yaml' => true irb(main):002:0> YAML => Psych
  - thibaut_barrere 14y ago
    It doesn't work for me either on 1.9 - anyone with an explanation? I commented here: https://gist.github.com/4507129 https://gist.github.com/4507129
    - sferik 14y ago
      The patch I applied does not use YAML.tagged_classes.
fowlduck 14y ago
Grape is also affected: https://groups.google.com/forum/?fromgroups=#!topic/ruby-grape/qX38Iy1Bwo8 https://groups.google.com/forum/?fromgroups=#!topic/ruby-gra...
fowlduck 14y ago
A version of multi_xml with this fix has been pushed: https://rubygems.org/gems/multi_xml/versions/0.5.2 https://rubygems.org/gems/multi_xml/versions/0.5.2
jfirebaugh 14y ago
I'm keeping track of a list of vulnerable gems here: https://gist.github.com/4532291 https://gist.github.com/4532291

44 points by fowlduck 14y ago

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

sferik 14y ago
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.
fowlduck 14y ago
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.
jmileham 14y ago
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.

kanzure 14y ago

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

cdcarter 14y ago
Though the 'twilio' gem does use HTTParty, 'twilio-ruby' doesn't. So just make sure to check your Gemspec.lock.
bradly 14y ago
Quick clarification: The multi_xml gem has _not_ been updated, so there is nothing to upgrade, correct? Just the monkey-patch fix?
- kanzure 14y ago
  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.
- sferik 14y ago
  A new gem release is in the works and should be pushed tomorrow. In the mean time, you can use this workaround.
- sferik 14y ago
  MultiXML version 0.5.2 is now released.
FuzzyDunlop 14y ago
Or reference HTTParty from git, which has been fixed, in your Gemfile: https://github.com/jnunemaker/httparty/commit/53a812426dd32108d6cba4272b493aa03bc8c031 https://github.com/jnunemaker/httparty/commit/53a812426dd321... Correction: Although this might not have much to do with multi_xml if that security risk isn't mitigated.
- fowlduck 14y ago

nelhage 14y ago

I strongly recommend loading something like this in your Ruby applications: https://gist.github.com/4507129 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.

bradleybuda 14y ago
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?
- sferik 14y ago
  YAML is aliased to Psych: irb(main):001:0> require 'yaml' => true irb(main):002:0> YAML => Psych
- thibaut_barrere 14y ago
  It doesn't work for me either on 1.9 - anyone with an explanation? I commented here: https://gist.github.com/4507129 https://gist.github.com/4507129
  - sferik 14y ago
    The patch I applied does not use YAML.tagged_classes.

fowlduck 14y ago

Grape is also affected: https://groups.google.com/forum/?fromgroups=#!topic/ruby-grape/qX38Iy1Bwo8 https://groups.google.com/forum/?fromgroups=#!topic/ruby-gra...

fowlduck 14y ago

A version of multi_xml with this fix has been pushed: https://rubygems.org/gems/multi_xml/versions/0.5.2 https://rubygems.org/gems/multi_xml/versions/0.5.2

jfirebaugh 14y ago

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