[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <FC72FC641B949240B947AC6F1F83FBAF26FC0BBC@IMCMBX01.MITRE.ORG>
Date: Thu, 15 Aug 2013 16:51:20 +0000
From: "Christey, Steven M." <coley@...re.org>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
"kseifried@...hat.com" <kseifried@...hat.com>, Marcus Meissner
<meissner@...e.de>
Subject: RE: rubygems insecure download (and other problems)
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
