CVE ID发行策略使用新的ID语法

所有,现在变长选项被选中,我们正在寻求董事会对几个问题的输入。我们正在寻求董事会协助沟通的语法变化,这将在一个单独的线程。这封邮件问候的最好策略发布CVE id开头“CVE - 2014”前缀,在2014 - 2015年过渡的一年。签发CVE id,我们看到两个重大问题:——我们是否应该避免作业CVE通过CVE - 2014 - 0001 - 2014 - 0999(避免任何“前导零”)——发行是否应该减少风险的情况下,id可能会无意中截断的四位id(“截断缓解”)主要零- - - - - - - - - - - - - - - -从2014年开始,应该CVE id按照前几年的实践,首先CVE - 2014 - 0001,或他们应该首先CVE - 2014 - 1000吗?一些董事会成员建议,我们可以避免使用领先的0 CVE id,即。,开始“cve - 2014 - 1000”而不是“cve - 2014 - 0001”。这种方法可以简化一些代码输出CVE id。我们发现第三方代码代表“cve - 2013 - 0123”不是一个字符串,但是两个整数列值:2013年和123年。然而,目前还不清楚我们的要求主要零输出构成任何重大技术成本。除了一些政党可能实现成本,还有其他的好处避免领导0 ?从cve - 2014 - 1000将在999年减少空间id之前需要5位数,这将减少的时间,供应商必须解决他们的实现,可能通过几个月的时间。 MITRE recommends continuing the practice of the past 14 years, and using the leading zeroes for only the first 999 IDs. TRUNCATION MITIGATION --------------------- For 2014, should our issuance strategy mitigate the potential risks when CVE IDs with 5 or more digits are issued, but the IDs are not properly handled by non-compliant implementations that assume only 4 digits? If a legitimate 5-digit ID is inadvertently truncated to a 4-digit ID, then this would cause incorrect CVE IDs to be used and adversely affect the exchange of vulnerability information. For example, suppose that both CVE-2014-1000 and CVE-2014-10007 are issued in 2014, and an advisory refers to CVE-2014-10007. An implementation that assumes 4 digits might inadvertently convert CVE-2014-10007 into CVE-2014-1000, which would be a completely different ID for a different vulnerability. Even if our communication strategy is highly successful, there is still a risk that either (1) some developers will not learn about the ID syntax change, or (2) some developers will not be able to fix their code in time. Based on some research we conducted earlier this year, we have seen a number of CVE-ID implementations in which 4 digits are assumed. The 4-digit assumption might be most prominent in code that (1) extracts or parses CVE IDs, or (2) outputs CVEs assuming a specific format or length. To minimize this risk, during 2014 only, we could avoid assigning a relatively small number of 4-digit IDs if there is a reasonable chance that a different, 5-digit ID could be assigned that has a risk of being inadvertently truncated to the original 4-digit ID. For example, the first 5-digit ID to be issued would be CVE-2014-10000; since this could be truncated to CVE-2014-1000, we could avoid assigning CVE-2014-1000 entirely. We could use this approach for a "protecting block" of IDs, such as CVE-2014-1000 through CVE-2014-1199 (200 IDs). This means that any 4-digit truncation of CVE-2014-10000 through CVE-2014-11999 would not map to a valid ID. Since the block of 2000 "protected" 5-digit IDs will almost certainly include IDs for high-profile vulnerabilities, users and developers of truncating implementations are likely to be alerted to the problem quickly. Also, the CVE-2014-1000 to CVE-2014-1199 protecting block is small enough (200 IDs) that it would make a negligible difference (2%) in the likelihood of reaching 10,000 IDs in 2014. Thus, there is an attractive 10-to-1 tradeoff between the number of protected IDs and the size of the protecting block. Our only known disadvantage is that reaching CVE-2014-10000 even 2% faster might adversely affect someone. The exact size and implementation of the protecting block would be determined later. If truncation mitigation is desired, then some potential ways to implement protecting blocks include, but are not necessarily limited to, (1) not assigning the protecting block IDs (e.g. CVE-2014-1000) at all, or (2) assigning protecting block IDs, but providing a description that emphasizes that the ID is not for public use and might indicate a truncation error. At this time, MITRE does not have a specific recommendation regarding whether truncation mitigation should be pursued, and we welcome opinions from the Board. We would appreciate everybody's feedback on these questions. Regards, The MITRE CVE Team