Ruby Security Have You Not
hakiri.io
hakiri.io
I'm one of the maintainers behind the Ruby advisory database: https://github.com/rubysec/ruby-advisory-db
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.
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.
It's the database that powers http://github.com/rubysec/bundler-audit and (disclaimer: I made this) https://gemcanary.com and the more people contributing the more we can all benefit from improving the ways we can notify end users of their vulnerable dependencies.
Thanks,
Also, how would one use bundler-audit if a Rails app is not actively maintained?
There's a few others but they've slipped my mind at the moment.
I use bundler-audit when performing security audits for clients. You could wrap it in a git commit hook and have it publish results, but to my knowledge no one's done it that way.
I'm not super-comfortable connecting private Github repos to remote web services. Github's (and other applications) recent OAuth exploits aren't very comforting and I'm generally the paranoid type.
Regarding Gemcanary, we're actually in the midst of building something just like that because we deeply hate storing Github tokens - but the ease of use was too good to not go for with our proof of concept. Once we release the new feature it'll be our goal to move as many people as possible away from giving us access to their private github repos.
Paolo
In my experience, vulnerabilities are pretty much endemic to software that has not been hardened by experts.
Even if the Python modules we have had the same number of vulnerabilities as gems, our exposure for a given system would be 1/10th, just from not using so many external libraries. Couple that with the fact that many of those gems are outside of end-user control, of generally unknown quality, might only be pulled in for one small piece of functionality, and might themselves depend on other gems which you weren't necessarily aware of and haven't necessarily vetted.
The flip side is actually knowing that this "meme generator" gem you are using actually pulls in 50 dependencies, many of which are terribly implemented. I've seen this problem just as rampant in the Node.js and jQuery worlds.
As developers, we should be as aware as possible of the state of our critical apps dependencies. I've recently gone through an app that had over 50 gem dependencies and reduced it to under 20.
One thing that's probably not considered is that testing frameworks (rspec) have tons of dependencies that are not scoped to production. I'm not sure if these reports considered that.
I've had a similar issue when using the Spring Framework in Java, where including it in your project at all brings a whole host of other (often not very good) libraries in. This is a problem in Java, which doesn't have any built in capacity for loading multiple versions of the same library.
In Python, I suspect that I've been in a similar situation when using things like Pyproj, Numpy or Scipy, because those all depend on components written in C or Fortran. Perhaps next time I use any of those libraries I shall take some time to read more of the code and try to trace out what things they may be brining in.
All of that, really. For better or worse, scores of gems have dependencies. Rails and a few popular others add large dependencies that cascade to other dependencies at that — some large, some not. It's extremely rare to run into quality gems with very few if any dependencies. (Sequel comes to mind, and that's just about the only 1st-class gem I can think of in pure Ruby.)
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.
The fact of the matter is, if you are developing an application and are integrating 3rd-party code, always pay attention to what that 3rd-party code is, how well-maintained it is, and how the project has responded to bugs and vulnerabilities in the past.
Edit: Can't take all the credit, client hacked together the first version but we managed to extract it for "the greater good." Also fun stuff like XML-RPC (Xen API -> gem xenapi, VMware (gem rbvmomi)), which wasn't bad and worked OOTB. Wished MS exposed their APIs as RESTful endpoints, because WinRM + gem winrm just doesn't cut it with some products... generated powershell run by an agent instead. For some products, even having the (.someextiforgot) files that describe the API, there's no MS docs on them, so lots of trial-and-error in PowerGUI to find the right objects and methods (Yuck).
https://github.com/steakknife/ruby-net-ldap
Shameless self-promotion: Clients call for this devil if something's hard or something's broken.
I'm now much more cognizant about stuff like how many contributors a project has and whether it is in active development.
Ruby: recompile with minimized OpenSSL 1.0.1+ (LibreSSL when possible) and with patches that improve Ruby's default OpenSSL security.
https://gist.github.com/steakknife/8228264
https://gist.github.com/steakknife/10092587
https://gist.github.com/steakknife/10096008
For Rails apps: use brakeman as one part of security audit strategy
For gem authors, sign them (please!): I wrote waxseal to make it dead simple
[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
Add this to ~/.gemrc gem line:
--trust-policy MediumSecurity
or just if there's no gem: .... already:
gem: --trust-policy MediumSecurity
The kind of graph being used here -- a "best fit" bell curve based on the sample mean/s.d. -- can be useful when overlaid on a histogram, to illustrate how closely the data can be approximated by a normal distribution. Without that context, it's essentially meaningless.
First one is finding, reporting and getting vulnerabilities.
Most people don't perform security audits. Most vendors take forever to reply back to security reports. Infuriatingly, many vendors will roll security fixes into the next major release instead of backporting patches and minor versions.
The second one is about finding out about disclosed and patched vulnerabilities.
Outside of larger institutions where you have someone whose job it is to worry over configuration management and subscribe to every mailing list, the ecosystem for disseminating this information is broken. That's why we've started the https://github.com/rubysec/ruby-advisory-db, at least for the Ruby ecosystem.
That doesn't even mean an exploit btw. Some of those gems might be in the Gemfile but never actually used (deprecated but not removed, hence not updated), or the vulnerable component might never be used. The gem might only be used on internal data, not user-manipulateable data.
Furthermore, you can't extrapolate 13% of the examined gemfiles containing such an issue to all gemfiles, which you did.
The fact that it's reported certainly doesn't mean it will be fixed in all downstreams (what this article refers to). Do you read every CVE? Every single one? Didn't think so. Most gems are relatively unpopular and any issues in them won't be widely publicized. Sure, Rails issues are shouted far and wide, but most of the rest are easy to miss.
Hell, some CVEs don't even get fixed in the gem itself, let alone all the consumers of that gem; the gem just remains vulnerable because there's no maintainer or the maintainer insists that it's "not an issue".
Please don't make such misinformed comments without even reading the article with sufficient attention to detail to get the statistic right.
The data used in the article contains a list of the versions being used in production by real app, not the latest versions released by the gem developers.
If it's a bug in a YAML parser but you're not loading YAML from untrusted sources, then it would be a false positive.
The should be able to calculate what percentage of these would still be vulnerable if fully updated - now that would be an interesting stat!
I'm not ready to speculate which is more probable.
Regard paolo@armoredcode.com
This article is incredibly misleading.
The second part focuses on historical vulnerability data for Ruby gems.
In what way any of it is misleading?
Why is that news?? That is true across every and all software platforms.
> In what way any of it is misleading?
Because the article assumes or implies the conclusion that there are a huge number of vulnerable Rails apps. The only way to discover that is to not simply count how many CVEs have been issued for each gem, but how many systems in production have not been patched.
From the comments here, many people seem to assume this is an analysis of the number of unpatched vulnerable systems in production, which it most definitely is not.
It's not exactly news but it's nice to see it broken down in a cohesive way.
> Because the article assumes or implies the conclusion that there are a huge number of vulnerable Rails apps.
I think the article quite clearly indicates where all data points came from (Hakiri Facets) and then analyzes them. There is a post scriptum at the end that encourages readers to not evaluate their or any other projects based on the number of CVE vulnerabilities and goes into detail why it's not always a great idea.
As a side note, I'd be interested to see a similar analysis of popular Java projects.