Date: Fri, 27 Dec 2013 11:22:10 -0500 (EST) From: cve-assign@...re.org To: vdanen@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, christian@...imes.de, psrt@...hon.org, kseifried@...hat.com Subject: Re: CVE issues with recent python flaws -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > One CVE (CVE-2013-1752) as assigned to all of these, which would have > been perfectly reasonable if they had _all_ been fixed simultaneously > (or at least in the same version). > https://bugzilla.redhat.com/show_bug.cgi?id=1046174 > Unfortunately, upstream assigned a single CVE to all of these MITRE is responsible for the CVE-2013-1752 assignment. (In other words, the upstream Python vendor was not responsible for deciding how many CVEs were originally assigned.) The background is that, months ago, MITRE received a request from an authoritative upstream vendor contact indicating that bugs 16037/16038/16039/16040/16041/16042 needed vulnerability remediation and that a CVE mapping was desired. At the time of the request, no fix had been released for any of the six bugs. As far as we could tell, all of the six pieces of affected code were shipped in the primary downloadable Python distributions. (In other words, they weren't third party components distributed elsewhere for use with Python.) The six pieces of code seemed to have the same type of implementation issue, so one CVE was assigned. We do realize that many CVE consumers rely on separate CVE IDs for vulnerabilities with different affected versions, and thus MITRE can generate the appropriate number of new CVE IDs (apparently either 4 or 5), and include explanatory references to the new CVEs within the upcoming "REJECT" entry at: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1752 The decision between 4 and 5 only depends on: imaplib  (not yet fixed in 2.7.x, fixed in 2.6.9 , 3.3.3 ) poplib  (not yet fixed in 2.7.x, fixed in 2.6.9 , 3.3.3 ) If anyone knows that the upstream vendor is specifically planning to fix imaplib and poplib in different 2.7.x versions, then these two will have separate CVE IDs, and the total will be 5. Otherwise (e.g., if both fixes are probably going to be in 2.7.7, or if just no one knows when the fixes will be shipped), then we assign the same CVE ID for imaplib and poplib, and the total will be 4. Finally, we had one comment about this: > Date: Thu, 26 Dec 2013 21:32:27 -0700 > From: Kurt Seifried > my personal take: these are very different code modules (different > protocols) so CVE split Differences in the implemented protocol typically aren't something that MITRE looks at in deciding how many CVE IDs are needed, as long as each protocol provides an opportunity for untrusted input to arrive. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJSvabzAAoJEKllVAevmvmsnukH/RfuVHsRTFQ/xlOSvTpjJEf6 /yGADoL8ES4VqwvhvYsmpro70UIDDlHthcLoqNG8vl3rTD50t6p1BvtQL/tMfg38 c4x6aKDTu69IiHDFB1glBC22Sx6qLyRTCLwhQsjKirKa9fCH1xlnPU7zRU7rOOVl c3R6mBZuHv2zg41TZYy+iraEtii4FTiQiKG+75X7xDAKVJJ3k6q7roiciHTZwsye 27/sZ/QalMWMgiYA6S/lQBcxO/AZYKS8ARWvmPZgNXpXuwYx4QTtLvd+GS518I48 0rlUAS1kFUsCd0VNC7vwTzr6w/FQZ6vfxABk8zjzfcsXBDnoi1QZ3nPlWHzmhsE= =7kEO -----END PGP SIGNATURE-----
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.