Re: Re: CVE request for code execution via gem name collission in bundler (was Re: [oss-security] CVE Request)

[Reed Loden <reed () reedloden com>]

I asked the Bundler team about this issue since this seemed to be lacking
details. They said that they attempted to fix this generic issue in Bundler
1.7 (see
http://bundler.io/blog/2014/08/14/bundler-may-install-gems-from-a-different-source-than-expected-cve-2013-0334.html),
and they were able to fix most of the issues.

However, there are some edge cases, which I think Steve is referring to.
Specifically, see https://github.com/bundler/bundler/issues/3671.
Additionally, see also https://github.com/bundler/bundler/pull/3696
(failing spec that shows the issue) and
https://github.com/bundler/bundler/pull/4714 (PR where the issue was fixed,
but only on Bundler 2.x branch).

The team was never able to remove all possibilities of namespace collisions
while keeping the existing lockfile format, which is why the fix was only
on Bundler 2.x.

~reed

On Tue, Oct 4, 2016 at 11:32 AM, <cve-assign () mitre org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> > I'd like to request a CVE to track a security vulnerability found in
> > Bundler (bundler.io <http://bundler.io/>). Bundler allows the user to
> > specify sources from which Ruby gems are installed. If a secondary
> > source is specified, even if scoped to a specific gem, that source is
> > silently applied to all declared gems. This allows an attacker to
> > introduce arbitrary code into an application via gem name collision on
> > the secondary source, which will unexpectedly (and without warning)
> > take priority over the primary source.
>
> Use CVE-2016-7954.
>
> - --
> CVE Assignment Team
> M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
> [ A PGP key is available for encrypted communications at
>   http://cve.mitre.org/cve/request_id.html ]
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJX8/U7AAoJEHb/MwWLVhi2xrwP/RjNz+PRsrpnt6grFruRj6rH
> IvSdysqLU3/+gK2Q+1mXtdydmkn05PMLHrB58Os6hP+K5POjPnNjXsc+VfaoD83r
> S4wmDBs3H4l3XMrT+WHOqvZWsF74iDlTSFA35DNLFRW6Ad5IwPNuMcUBE8yqlMyK
> SQ6aU0BvwB7yygmeK6RBvDICsUthcyrTooXkmeDKe1EhRxgKXwdvFVeknKiCOneK
> hTMvNl6MyWU6BW3W0AelJG0mcndEu9Ai7DUf50mgCtuJCLay0wKLn8QrcYg7dWR8
> 17xFYh8v3soNMNrWBhyKcJUxWPz/YhNKbqjvXnk4Q1BIiEaBmYL4/Mw08dj+nKmy
> 2LTE+Kcx9vKHedo6lNT/Qxuug+S1czmbGESfygWACDpl2frB9YwVaU8MbFxZkfVj
> utU9+zrQBhRQXUw9ZMN83dJqqiC8956/IGWczI++rvp8cqrMETP91PueK23wE091
> SEzfASXty4n2HdD4AWwg0caECoDeUiDZP8UrQkkLDYu9Xlyeqw9C1vgiATTT3Uni
> bTFjnBhrohCXEh/uvoWJIqZZbO8DRQ0KWI6FlcDuDzubGrih0M4CM7KZ0bDRpwGC
> 9VGbDtdGK0XPOzzHvPUr+GDSjwZCJ0aFTaxlxwa+ol15mLKyBWCkLHd/8NYHvM5E
> is4rHDl4O1P83Wx0+Er0
> =RpXj
> -----END PGP SIGNATURE-----