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 gem name collission in secondary sources #379

Open
sfcgeorge opened this issue Oct 6, 2016 · 4 comments
Open

CVE-2016-7954 gem name collission in secondary sources #379

sfcgeorge opened this issue Oct 6, 2016 · 4 comments

Comments

@sfcgeorge
Copy link
Contributor

sfcgeorge commented Oct 6, 2016

See my comment on this issue in Bundler for more info and this blog post for full explanation and workaround. TLDR: Using source blocks around 3rd party gems supposedly doesn't prevent name collisions in gem resolution outside of those blocks. This might be fine if you trust 3rd party gem sources. As a popular 3rd party source I thought I'd report it to you, not to suggest you're evil, but perhaps so you can add a note to the documentation for anyone who wants to be extra safe.

Something like:

source 'https://rubygems.org' do
  gem 'bundler', '>= 1.8.4'

  gem 'rails'

  gem 'sass-rails'
  gem 'uglifier'
  gem 'coffee-rails'
end

source 'https://rails-assets.org' do
  gem 'rails-assets-bootstrap'
  gem 'rails-assets-angular'
  gem 'rails-assets-leaflet'
end
@hut8
Copy link
Member

hut8 commented Oct 6, 2016

What's the difference between that and this? http://bundler.io/blog/2014/08/14/bundler-may-install-gems-from-a-different-source-than-expected-cve-2013-0334.html

The instructions don't use the block syntax but are careful to specify that you must include the source as an argument and not just write a second source statement at the top of the gemfile.

@hut8
Copy link
Member

hut8 commented Oct 6, 2016

Ohhhh wow! That is a vulnerability. I get it; the source is silently applied to all of them! PRs for documentation welcome; I can't get to this today but probably can by early next week.

@sfcgeorge
Copy link
Contributor Author

@hut8 Yup. TLDR as Steve's blog post explains the fix didn't fix it, adding a source argument or block doesn't fully prevent lookup collisions.

Okay I'll see if i can PR if you think a doc mention is a good idea :)

@sfcgeorge
Copy link
Contributor Author

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

I'm struggling to think of a real world way this could be exploited. With RailsAssets this would only be an issue if you got hacked so someone could add a fake "rails" as you namespace everything usually, but equally they could just hack "rails-assets-jquery" so I'm not sure if this bug introduces any more risk than the trust people already have to have. I guess it's better to play safe, I'm no security expert.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants