RE: rubygems insecure download (and other problems)

["Christey, Steven M." <coley () mitre org>]

Kurt asked:

> Can someone generate a list of all the client software that pulls gems
> insecurely from rubygems.org and post it here? thanks. I can't assign
> CVE's to services, only to software.

Just some quick thoughts here...

Downloading and automatic execution of code without ensuring its integrity does have precedent in CVE, as already noted.

However, we might want to further narrow CVE's scope to issues in which:

1) The rubygems.org site is hard-coded or default, and

2) The installation/update is performed automatically (or semi-automatically) in a way that the sysadmin cannot 
directly influence or otherwise validate the code.

For item 1, we don't want to assign CVEs if the admin *could* configure something to use unsafe sources, but the 
default is safe.

For item 2, maybe there are cases where the gem's sysadmin is expected to download the gem and compare the download's 
hash against a separately-published list of hashes.  (I don't know if this is the case.)  In this context, there is 
clearly an expectation for the sysadmin to perform the verification, and we don't often assign CVEs for cases when 
sysadmins do not follow vendor instructions.  If the product's installation documentation and/or vendor web page 
includes some kind of validation step (such as hash-checking), then this might not qualify for a CVE.


Marcus Meissner said:

> I think a "package management" solution that installs software on a system should
> have good security measurements by default these days, and trivial man-in-the-middle
> attacks should not be possible.

I think I agree.  This is not like the "old days" when there was no other recourse (or when there was a dependency on 
the sysadmin to validate hashes or do other integrity checks).  The increasing connectedness of software, and 
especially the increasing automation of code distribution or upgrades, makes this a bigger problem than it used to be.

- Steve