Hacker News Reader

Comment by nestlequ1k | Hacker News Reader

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

View on HN

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/...

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

There are other workarounds, too. You could disable XML parameter parsing, for example (as seen here: 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.

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.

    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)

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.

A smart attacker would install a backdoor and update rails.

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.

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.

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, then you'll get a quick check for just the YAML vulnerability.

Does that clarify it a bit?

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.

While it won't cover all situations, Brakeman has been updated to warn about arbitrary YAML loads:

http://brakemanscanner.org/

[edit] This is a code analyzer.

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

Reply on news.ycombinator.com