CVE-2016-7954 secondary sources #5051

Open
wwood opened this Issue Oct 5, 2016 · 4 comments

Projects

None yet

4 participants

@wwood
wwood commented Oct 5, 2016

Hi,

I'm just wondering where the code is at re this vulnerability? Is there a fix?
http://seclists.org/oss-sec/2016/q4/18

Apologies if I missed the answer to this q elsewhere.
Thanks, ben

@indirect
Member
indirect commented Oct 5, 2016

Hi there. No one has contacted the Bundler team in any way regarding this vulnerability yet. We believe that we have already fixed the issue in an upcoming release, but there is no way to tell, since no one has bothered to give us the details of the supposed CVE.

@sfcgeorge

What I could find:

  • 2015-05-21 This issue was reported that appears to be the same thing. Closed; as it's fixed in 2.0 (but not 1.x).
  • 2016-04-01 The blog post below suggests the Bundler team was contacted in April by email. No details of the contact. Searching the mailing list for "secondary source" and "CVE-2016-7954" comes up with nothing.
  • 2016-10-04 CVE was requested and "reserved".
  • 2016-10-04 Reed Loden's comment says further contact was made with the response that the 2.0 fix can't be backported to 1.x due to lockfile incompatibility.
  • 2016-10-06 Steve Richert wrote this blog post about the CVE which he reported (I saw it on twitter). There are GIFs that appear to show a replication (I realise GIF immediately suggests 🐱 but it seems convincing).

Could this be a security issue in real world production environments? One thing that springs to mind is Rails Assets so I've opened a feeler issue there. Of course GitHub and Bitbucket inline sources are common too.

If it could be a real security issue, and assuming a fix can't be backported, should a warning be added suggesting the no top level source using only blocks workaround?

Was the team contacted, what was the actual response? How does RubyTogether fit into this, would additional funds from concerned parties help? Does RubyTogether prioritise security fixes (I don't see it on the site)?

I'm just collating info that may or may not be helpful, not trying to stir alarm or anything. You all do a great job, and it's really appreciated 💟

@sfcgeorge sfcgeorge added a commit to sfcgeorge/rails-assets that referenced this issue Oct 6, 2016
@sfcgeorge sfcgeorge Change Gemfile example to use block for rubygems
This is instead of global as there is a security issue
bundler/bundler#5051
b0fb70b
@sfcgeorge sfcgeorge added a commit to sfcgeorge/rails-assets that referenced this issue Oct 6, 2016
@sfcgeorge sfcgeorge Document using a block instead of global source
This is in reference to a security issue
bundler/bundler#5051
a8da6e5
@sfcgeorge sfcgeorge added a commit to sfcgeorge/rails-assets that referenced this issue Oct 6, 2016
@sfcgeorge sfcgeorge Add link to post about source block for security
This is in reference to a security issue
bundler/bundler#5051
8b1d6b0
@sfcgeorge

I've been able to verify this affects git and github remotes too - all gemspecs in that single repo will be considered for all global gems. https://github.com/sfcgeorge/gem_clash

However I'm struggling to think of a real world way this could be exploited. It would be easier for a rogue gem author to add malicious code to their own gem than add a second fake gem for "rails" or whatever.

@lynnco
Member
lynnco commented Oct 7, 2016

Here is our plan to address this so far: #5062

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment