Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2016-7954 secondary sources #5051

Closed
wwood opened this issue Oct 5, 2016 · 5 comments

Comments

Projects
None yet
5 participants
@wwood
Copy link

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

commented Oct 6, 2016

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 added a commit to sfcgeorge/rails-assets that referenced this issue Oct 6, 2016

Change Gemfile example to use block for rubygems
This is instead of global as there is a security issue
bundler/bundler#5051

sfcgeorge added a commit to sfcgeorge/rails-assets that referenced this issue Oct 6, 2016

sfcgeorge added a commit to sfcgeorge/rails-assets that referenced this issue Oct 6, 2016

@sfcgeorge

This comment has been minimized.

Copy link

commented Oct 7, 2016

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.

@lynncyrin

This comment has been minimized.

Copy link
Member

commented Oct 7, 2016

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

@colby-swandale

This comment has been minimized.

Copy link
Member

commented Feb 21, 2017

This issue has been quiet for a while now and i feel that there is nothing left to add to this specific ticket. I'm going to close it for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.