公共使用的CVE id在id名称保护街区

最近,一些CVE IDs在保护块已经公开引用,这是造成一些混乱。这个消息是为了解释造成了混乱的情况下,我的意思是如何解决它。发布的编辑委员会2014年1月去年[1],以及宣传的CVE网站大约相同的时间[2],我们实现了一个“保护块”来处理潜在的截断误差情况下的CVE id。保护块覆盖了IDs之间cve - 2014 - 1000和cve - 2014 - 1200,包容性。这些id不分配给任何人。保护块被实现为一个故意CVE-ID空隙空间由CVE完全排除条目——甚至不保留或拒绝免责声明。中列出的条目甚至CVE下载。目的是引发致命错误当人们试图查找CVE-ID并不存在;截断的cve cve - 2014 - 2014 - 10000 - 1000,例如,可以间接地提醒用户问题时找不到cve - 2014 - 1000。intentionally-planned功能,这是自2014年初以来,技术指导页面上的记录:因为这些id不存在,任何无意的使用可能会产生一个明显的错误在CVE-using实现中,这可能会提醒用户(和供应商)可能的截断。 Unfortunately, we now have a case in which the protection block "worked." It triggered surprising errors that were noticed by consumers - but the errors were not due to inadvertent truncation. The situation arose as follows: 1. For some reason we don't yet know, a particular researcher has been making a small number of disclosures that list CVE IDs within the protection block, such as CVE-2014-1137. Needless to say, these IDs were not assigned to the researcher, who has also made incorrect mappings to legitimate IDs for unrelated issues. This public usage of protected IDs is the trigger for the resulting confusion. 2. Whenever there is an attempt to access a protected ID on cve.mitre.org, we have a custom CVE page that explains the protection block, such as:http://cve.mitre.org/cgi - bin/cvename.cgi?name=cve - 2014 - 1137这个自定义错误页面的目的是提醒用户保护街区。3所示。在这种情况下,自CVE保护街区,它生成的自定义错误页面关于截断——然而,CVE - 2014 - 1137的使用并不是由于截断。4所示。随着这种情况的发展(带有少量披露),我问CVE内容团队成员创建一个单独的CVE标识符——官方条目,使用不正确的ID作为一个关键字,这可能有助于找到合适的ID时在CVE网站上更新的条目。然而,我们没有填充protection-block ID与一个关联的“* *拒绝* *”声明,我们没有参考官方ID。例如,public-seeming ID (cve - 2014 - 1137)不可能没有发现,而其明显的重复(cve - 2014 - 9445)发表没有提及cve - 2014 - 1137。回想起来,这是一个错误。5。官方出版的“复制”ID OSVDB造成的混乱,并可能在别处。OSVDB,他们使用“grep”原始CVE下载找到保护ID,当然这个搜索失败了。 However, the person doing the analysis apparently did not consider that the ID was within the protection block. 6. Further exacerbating the problem is the timing of this situation, when we are literally days away from issuing 5-digit and 6-digit IDs, where the protection block is more likely to serve its intended purpose of alerting users and vendors who have errors in their CVE-ID management. In this situation, the protection-block message was a red herring. Interestingly, CVE-ID typos and even 5-digit IDs have been mistakenly referenced in the past year, which has led to non-existent CVE entries that should have been noticed in a similar fashion; yet, apparently, these did not cause any trouble or confusion. So, it must be the use of an ID within the protection block that contributed to significant confusion this time. Moving forward, the current plan is: 1. We have already attempted to contact the researcher to get them on the right track about CVE assignment. 2. We will create REJECTed entries for the protected IDs being referenced. This will happen today. 3. We will change the text of the error messages to better emphasize the protection block while allowing for other situations such as typos. I plan to do this in the upcoming days. 4. For any official, MITRE-assigned CVE-ID, we will consider adding a NOTE statement to reference the self-assigned ID. I hope this explains the situation sufficiently. - Steve References: [1]http://cve.mitre.org/data/board/archives/2014-01/msg00000.html[2]http://cve.mitre.org/cve/identifiers/tech-guidance.html extraction_or_parsing