Hey!<p>I'm one of the maintainers behind the Ruby advisory database: <a href="https://github.com/rubysec/ruby-advisory-db" rel="nofollow">https://github.com/rubysec/ruby-advisory-db</a><p>We're trying to build a common database for people building these tools; at the moment, trawling through CVE disclosures and various mailing lists is a largely manual process that we can reap economies of scale by pooling our efforts together.<p>It's free and volunteer run. I would like to encourage you and anyone else reading this who is interested in bolstering the security ecosystem to consider using and contributing to the advisory database.<p>It's the database that powers <a href="http://github.com/rubysec/bundler-audit" rel="nofollow">http://github.com/rubysec/bundler-audit</a> and (disclaimer: I made this) <a href="https://gemcanary.com" rel="nofollow">https://gemcanary.com</a> and the more people contributing the more we can all benefit from improving the ways we can notify end users of their vulnerable dependencies.<p>Thanks,
I can't help but feel that this could also be written as "How secure are Ruby and Rails apps? About as secure as all other apps."<p>In my experience, vulnerabilities are pretty much endemic to software that has not been hardened by experts.
This doesn't surprise me, and I'm not even an experienced Rails developer.<p>I think a big part of the problem is that there are a ton of gems that are simply hobby projects that gained traction and became popular. They were originally architected by enthusiasts, rather than experts. Some of these projects may also have been abandoned by their authors, but still in use because they may be the only way to accomplish a complex task or integration. You can't expect stuff like that to be very secure. You just have to think carefully about whether the risks of using them are worth the gains made from not having to implement the functionality yourself.
Generally: don't trust anything from the outside world or anything that can transit untrusted infrastructure, that means check types and sanitize values before passing along. Break loudly and quickly to get attention for a fix. Keep the codebase as tiny as possible too.<p>Ruby: recompile with minimized OpenSSL 1.0.1+ (LibreSSL when possible) and with patches that improve Ruby's default OpenSSL security.<p><a href="https://gist.github.com/steakknife/8228264" rel="nofollow">https://gist.github.com/steakknife/8228264</a><p><a href="https://gist.github.com/steakknife/10092587" rel="nofollow">https://gist.github.com/steakknife/10092587</a><p><a href="https://gist.github.com/steakknife/10096008" rel="nofollow">https://gist.github.com/steakknife/10096008</a><p>For Rails apps: use brakeman as one part of security audit strategy<p>For gem authors, sign them (please!): I wrote waxseal to make it dead simple<p><pre><code> [sudo] gem cert --add <(curl -L https://gist.github.com/steakknife/5333881/raw/gem-public_cert.pem) # adds my cert (do once)
[sudo] gem install waxseal --trust-policy HighSecurity
</code></pre>
For gem users, find which aren't signed<p><pre><code> Add this to ~/.gemrc gem line:
--trust-policy MediumSecurity
or just if there's no gem: .... already:
gem: --trust-policy MediumSecurity
</code></pre>
For anyone using git, sign your tags (git tag -s ...) and commits (git commit -S ...) por favor
More alarming than vulnerable gems is the the number oh high severity vulnerability found in Rails itself: <a href="http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043" rel="nofollow">http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-...</a>. Compare this to Django (<a href="http://www.cvedetails.com/vulnerability-list/vendor_id-10199/product_id-18211/year-2013/Djangoproject-Django.html" rel="nofollow">http://www.cvedetails.com/vulnerability-list/vendor_id-10199...</a>) per year.
The graphs of Gem distribution and Vulnerability distribution are utter nonsense. You can't just measure your mean and standard deviation and expect a bell curve that fits those two parameters to correspond to your distribution. <i>Especially</i> if you cut off one of the tails.
I am not a ruby developer, but it does seem shocking that 66% of all gemfiles contain a known previously-disclosed 5+ exploit. Yes, most software is flawed, but you would think once it's been reported, it would be fixed.
It's possible some of these are false positives, at least with regards to Rails, as most of the recent vulnerabilities I can remember come with workarounds and patch files. Some people need to stay on a specific Rails version, but may have fixed the problem.<p>I'm not ready to speculate which is more probable.
Hi there I'm the man behind the codesake-dawn security scanner for ruby code. It will be great having some of you comparing the results obtainw with haikiri or other scanner and mine. Just for sake to reach an enterprise level tool.<p>Regard
paolo@armoredcode.com
This article kind of confuses me - what does it mean for a gem do be 'secure' ? The idea of many gems being 'secure' or 'non-secure' is a non-sequitur. Obviously for some projects, like Rails, it's fairly clear what is meant when someone talks about a vulnerability - that you can hacked somehow. However, if someone wrote a gem to wrap eval into a command line tool so they can use some random ruby commands or libraries from their shell, well, secure would be a non-sequitur, but also beside the point.
This doesn't surprise me in the least, but the increase in 2013 is obviously due to increased security scrutiny, which is good so long as people act on that information.<p>As a side note, I'd be interested to see a similar analysis of popular Java projects.