Maybe create a gem?

[douglascamata]

Do you think it is possible to create a gem to automatically check if you have a "leaky gem" installed?

I know that if you have a Gemfile it would be pretty easy to implement a command to check this. If you use Rails creating an initializer to do the same thing is also easy. But is it possible to check gem versions at "require" time?

[sergey-alekseev]

@douglascamata yes, that's my initial idea.
However creating a gem takes a bit time. On the contrary testing the general idea as a simple gems list takes a little effort. I think the idea's testing is successful, so I'm going to create a gem soon. Thanks for your proposal and confirming my initial thoughts.

Leaving this issue open until I create a gem.

[douglascamata]

@sergey-alekseev remember to update here when you start the gem, I want to contribute 👍

[somazx]

bonus points if your gem checking for leaky gems itself leaks memory 😛

[douglascamata]

@somazx it can be a hidden feature, like an easter egg, lol

[grosser]

How about adding as advisory to bundler-audit then it can live with all the other gems and we do not need different mechanisms

[douglascamata]

@grosser it's a nice idea! But I also would love to see it working without bundler too, if possible. And I think it is better if I need only 1 line of code in the main file of my project to activate the verification at require-time than a command that I need to run.

[grosser]

How would you know what gem version is used if not for a Gemfile.lock ... so you need bundler ...

[douglascamata]

@grosser dunno how I would check that without bundler yet, but it might be possible somehow :P

[douglascamata]

irb(main):001:0> require 'middleman'
=> true
irb(main):002:0> Gem.loaded_specs["middleman"].version
=> #<Gem::Version "3.4.0">

[grosser]

That does not mean that your app is actually using that version of the gem
... it's just a random gem that was installed on your machine.

I'd prefer something simple/useful/integrated instead of
one-off/hacky/standalone :)

On Wed, Oct 21, 2015 at 2:09 PM, Douglas Camata [email protected]
wrote:

=> true
irb(main):002:0> Gem.loaded_specs["middleman"].version
=> #

—
Reply to this email directly or view it on GitHub
https://github.com/ASoftCo/leaky-gems/issues/2#issuecomment-150024976.

[douglascamata]

@grosser this is the actual version of the gem that was loaded by the require statement. It's not a just random gem installed on my machine. Gem.loaded_specs is only populated when you actually require a gem and it uses information of the gem's gemspec file.

I don't like bundler-audit because of the command, as I said. You need to have the habit of running bundle audit. With my suggestion you will just need to put one line of code in your project to be remembered that a gem version leaks memory every time you require it. It's very simple to do this, it's useful and integrated into your code.

[grosser]

If you don't use bundler then a require will load a random version of the
gem,
so to do anything meaningful we need bundler anyway ... so it's pointless
to build something bundler-agnostic.

Same can be done by making bundler-audit requirable, which adds the feature
for it's security checks and nobody needs to add a separate dependency to
another project.

(FYI checking on require will wastes startup time, adds another dependency
to the project, and means that the check is failing if not constantly
bundle-updating the gem ... so much more inconvenient then adding bundle audit --update to CI)

On Wed, Oct 21, 2015 at 3:23 PM, Douglas Camata [email protected]
wrote:

@grosser https://github.com/grosser this is the actual version of the
gem that was loaded by the require statement. It's not a just random gem
installed on my machine. Gem.loaded_specs is only populated when you
actually require a some gem and it uses information of the gem's gemspec
file.

I don't like bundler-audit because of the command, as I said. You need to
have the habit of running bundle audit. With my suggestion you will just
need to put one line of code in your project to be remembered that a gem
version leaks memory every time you require it. It is very simple to do
this, it's useful and integrated into your code.

—
Reply to this email directly or view it on GitHub
#2 (comment).

[grosser]

rubysec/bundler-audit#116

[douglascamata]

@grosser I don't see the issue of random version of the gem picked if you don't use bundler as part of the gem's problem. This gem responsibility would be just check if the loaded gem version leaks memory, it doesn't matter how the gem got there. But talking real, everyone uses bundler, so the correct version of the gem will be loaded and verified.

I also think a little startup time wasted in development/test is a fair price to pay for automatically checking these things that can give a big headache in production. Adding to CI is nice, but what if you don't have CI for whatever the reason?

Anyway, let's see what bundler-audit guys says about your question. And just to make it clear, I really liked your suggestion about bundler-audit integration and IMHO we should do both ideas.

[grosser]

• zipruby heap overflow and information leak in zipruby rubysec/ruby-advisory-db#207
• redcarpet is already included
• sidekiq add sidekiq memory leak advisory rubysec/ruby-advisory-db#208
• therubyracer ruby racer leaks memory rubysec/ruby-advisory-db#209
• grape grape leaks memory rubysec/ruby-advisory-db#210
• celluloid celluloid rubysec/ruby-advisory-db#211

[sergey-alekseev]

Thanks @douglascamata and @grosser for your considerations.
bundler-audit seems really useful. However they say it "Checks for vulnerable versions of gems in Gemfile.lock". It's a bit different from "leaky versions of gems". So no wonder they consider those memory leaks are not vulnerabilities (1, 2, 3) and requesting CVE/OSVDB ids (1, 2, 3, 4).

I'm open to all 3 options @grosser mentioned in rubysec/bundler-audit#116 (comment). An integration with bundler-audit would be nice.

[phillmv]

Hey,

Thanks for the effort everybody. The ruby-advisory-db is mostly about classes of bugs that are can be abused maliciously. What exactly constitutes a "vulnerability" is a bit of a philosophical point but @grosser you were correct in suspecting that many of them could belong in the advisory-db 😃.

We do impose a bit of a hurdle in that we aggregate advisories that have been published or somewhat vetted elsewhere, i.e. the requirement that notices contain a CVE or osvdb. For the most part, a lot of these memory bugs could very well be applicable.

---

For your purposes, I would suggest adopting the ruby-advisory-db schema (minus the CVE/OSVDB requirement) and then forking bundler-audit to slurp down that database instead.

The above analysis regarding depending on bundler is correct - runtime checks are annoying to implement properly :).

[sergey-alekseev]

@phillmv thanks for your input on this. Let me confirm you recommend the 3rd option @grosser mentioned in rubysec/bundler-audit#116 (comment):

make new gem that checks new database by running bundle-audit with some funky hacks/arguments

[grosser]

Something that just changes the url would be great ... maintaining a fork is not fun :)

[douglascamata]

What about we submit a patch do rubysec/bundler-audit with support to using multiple/another databases and, of course, use ruby-advisory-db as default? Or maybe command-line option to check for memory leaks instead of bug can be abused maliciously?

[sergey-alekseev]

Closed by https://github.com/rubymem/bundler-leak. 🎉

Thanks @bronzdoc! Learn more here.

[bronzdoc]

@sergey-alekseev thank you! for creating the leaky-gems db!

Credit should also be given to @etagwerker and @fastruby who helped bring it to life!

[grosser]

FYI asking if bundler-audit is willing to include the db as a optional check rubysec/bundler-audit#223