4 ms·

anyone have an open source command line tool to do this? call me paranoid (and probably dumb) but I really dont want to enter this into another website

borski 14y ago
I can tell you we're trustworthy, but I hear where you're coming from. :) With that said, you can use Metasploit for this too - we just wanted to make a really easy checker for those that wanted a quick OK/NO GO and didn't want to deal with setting Metasploit up. Metasploit docs here: https://community.rapid7.com/community/metasploit/blog/2013/01/10/exploiting-ruby-on-rails-with-metasploit-cve-2013-0156 https://community.rapid7.com/community/metasploit/blog/2013/...
- nimblegorilla 14y ago
  You are providing a valuable service, but is Metasploit really necessary for this? I think this is a simpler command: 'grep rails Gemfile.lock' If you don't see a rails version of 3.2.1, 3.1.10, 3.0.19, or 2.3.15 then you are vulnerable. Yes? I guess in theory an attacker could have compromised your server and changed the rails version number...
  - ainsleyb 14y ago
    There are other workarounds, too. You could disable XML parameter parsing, for example (as seen here: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...). Thus, you might be running an old version, but still actually be safe by disabling the vulnerable bits.
  - px43 14y ago
    We use old rails, but not the affected activerecord components. Also, there are more yaml bugs in existence than the ones publicly talked about, and this would detect those issues as well.
  - ef4 14y ago
    3.2.1 is not safe (you probably meant 3.2.11) 3.0.19 is not safe (3.0.20 was released to fix CVE-2013-0333) 2.3.15 is not safe (2.3.16 was released to fix CVE-2013-0333)
    - nimblegorilla 14y ago
      Good point. I just copied the version numbers from the linked website - I guess it was outdated. Although I checked again and they are correct now.
  - lucian1900 14y ago
    A smart attacker would install a backdoor and update rails.
  - rst 14y ago
    Rails 2.x apps aren't necessarily using Bundler at all, and some folks may have disabled the vulnerable parsers, or installed the security patches only into an earlier version to avoid other breaking changes or new deprecations. (Rails-core has gotten better at avoiding this kind of collateral damage from upgrades, but some folks are still gun-shy.) Actually probing the running app really is the only way to be sure.
- px43 14y ago
  Your scanner says 3 issues on my domain, but rails_xml_yaml_scanner instantly says none. Is your scanner scanning for more than the yaml thing? I don't really have access to just modify a production system on the fly to go through your verification process, and I don't want to go through all the trouble if it's just some nessus nag. It's confusing because it says three issues, but low impact. I thought I was only scanning for a yaml flaw, and yaml flaws typically lead to remote code exec. edit : I somehow stumbled into the full scanner on the main site rather than using the yaml scanner, my bad.
  - ainsleyb 14y ago
    Sorry about the confusion. If you run a scan from our homepage, you're actually looking for a lot more than just the YAML vulnerability (XSS, Mixed Resource, etc.) as our product isn't limited to just the YAML vulnerability. If you run the scan from https://www.tinfoilsecurity.com/railscheck https://www.tinfoilsecurity.com/railscheck, then you'll get a quick check for just the YAML vulnerability. Does that clarify it a bit?
    - px43 14y ago
      Ah, not sure how I got turned around, but yes I was using the scanner from the main page. Thanks for the clarification, and nice work. This is going to help out a lot of people.
ams6110 14y ago
If you don't do it, someone else will. And likely with less pure intentions.
look_lookatme 14y ago
While it won't cover all situations, Brakeman has been updated to warn about arbitrary YAML loads: http://brakemanscanner.org/ http://brakemanscanner.org/ [edit] This is a code analyzer.

borski 14y ago

I can tell you we're trustworthy, but I hear where you're coming from. :) With that said, you can use Metasploit for this too - we just wanted to make a really easy checker for those that wanted a quick OK/NO GO and didn't want to deal with setting Metasploit up. Metasploit docs here: https://community.rapid7.com/community/metasploit/blog/2013/01/10/exploiting-ruby-on-rails-with-metasploit-cve-2013-0156 https://community.rapid7.com/community/metasploit/blog/2013/...

nimblegorilla 14y ago
You are providing a valuable service, but is Metasploit really necessary for this? I think this is a simpler command: 'grep rails Gemfile.lock' If you don't see a rails version of 3.2.1, 3.1.10, 3.0.19, or 2.3.15 then you are vulnerable. Yes? I guess in theory an attacker could have compromised your server and changed the rails version number...
- ainsleyb 14y ago
  There are other workarounds, too. You could disable XML parameter parsing, for example (as seen here: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/61bkgvnSGTQ https://groups.google.com/forum/?fromgroups=#!topic/rubyonra...). Thus, you might be running an old version, but still actually be safe by disabling the vulnerable bits.
- px43 14y ago
  We use old rails, but not the affected activerecord components. Also, there are more yaml bugs in existence than the ones publicly talked about, and this would detect those issues as well.
- ef4 14y ago
  3.2.1 is not safe (you probably meant 3.2.11) 3.0.19 is not safe (3.0.20 was released to fix CVE-2013-0333) 2.3.15 is not safe (2.3.16 was released to fix CVE-2013-0333)
  - nimblegorilla 14y ago
    Good point. I just copied the version numbers from the linked website - I guess it was outdated. Although I checked again and they are correct now.
- lucian1900 14y ago
  A smart attacker would install a backdoor and update rails.
- rst 14y ago
  Rails 2.x apps aren't necessarily using Bundler at all, and some folks may have disabled the vulnerable parsers, or installed the security patches only into an earlier version to avoid other breaking changes or new deprecations. (Rails-core has gotten better at avoiding this kind of collateral damage from upgrades, but some folks are still gun-shy.) Actually probing the running app really is the only way to be sure.
px43 14y ago
Your scanner says 3 issues on my domain, but rails_xml_yaml_scanner instantly says none. Is your scanner scanning for more than the yaml thing? I don't really have access to just modify a production system on the fly to go through your verification process, and I don't want to go through all the trouble if it's just some nessus nag. It's confusing because it says three issues, but low impact. I thought I was only scanning for a yaml flaw, and yaml flaws typically lead to remote code exec. edit : I somehow stumbled into the full scanner on the main site rather than using the yaml scanner, my bad.
- ainsleyb 14y ago
  Sorry about the confusion. If you run a scan from our homepage, you're actually looking for a lot more than just the YAML vulnerability (XSS, Mixed Resource, etc.) as our product isn't limited to just the YAML vulnerability. If you run the scan from https://www.tinfoilsecurity.com/railscheck https://www.tinfoilsecurity.com/railscheck, then you'll get a quick check for just the YAML vulnerability. Does that clarify it a bit?
  - px43 14y ago
    Ah, not sure how I got turned around, but yes I was using the scanner from the main page. Thanks for the clarification, and nice work. This is going to help out a lot of people.

ams6110 14y ago

If you don't do it, someone else will. And likely with less pure intentions.

look_lookatme 14y ago

While it won't cover all situations, Brakeman has been updated to warn about arbitrary YAML loads: http://brakemanscanner.org/ http://brakemanscanner.org/ [edit] This is a code analyzer.