CVE-2016-7954 secondary sources

[wwood]

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]

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.

[indirect]

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]

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]

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.

[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.

[lynncyrin]

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

[lynncyrin]

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

[colby-swandale]

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.

[colby-swandale]

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.