再保险:定义什么是CVE值得下载/安装和容器

在星期二,2016年6月7日下午14点,常见的漏洞和风险敞口<cve@mitre.org>写道:

库尔特-

你非常清楚,CVE作业从来都不是一门精确的科学。以下是我们目前的实践的描述:

·的问题是否“软件代理完全按照设计”取决于谁发送CVE ID请求。例如,它是合理的供应商的服务器来提供相同的可执行代码(或更新服务)通过HTTP和HTTPS URL硬编码到一个客户端产品——通过设计应该从HTTPS开始,但它从HTTP偶然。因此,如果它是一个vendor-initiated CVE ID标记请求所需的安全更新他们的客户,然后请求总是接受的CVE ID。

·如果CVE的起源ID请求似乎无关的,写代码,然后(有时但不是100%的时间)CVE ID请求被拒绝,建议咨询供应商。

·很难达到100%的拒绝,即使CNA想,因为这个人发送CVE ID请求可能忽视了,或者不愿提及,问题的确切性质。一大部分的人认为,它总是一个漏洞对于任何产品,不断使可执行代码在未加密的HTTP请求,没有其他完整性保护,每当接收到响应和执行代码。因为这是明显的在他们的世界观,他们的漏洞描述可能专注于其他细节,操纵文件格式等。

·我们的主流观点是,HTTP /可执行代码的情况下,最好的一个中央社所能做的就是分配CVE id在这种情况下,他们相信CVE消费者希望这些id存在。如果请求者发送一个可信的描述开发可能性高,而且没有反诉从供应商本身,这是“软件代理一样设计,那么它能有资格拥有CVE ID。

如果人们要求CVE定义的安全漏洞他们希望他们存在。以及用户的各种开源和闭源产品我想是一个明智的消费者,目前最简单的方法是用cf(问题是合并在一个容易搜索数据库,而不是许多供应商网站(故意)很难找到关于他们的产品的安全信息。

这对于华硕比赛发生了什么(供应商拒绝回应)。如果另一个请求者不描述开发可能性或断言,基本上没有开发可能性,然后从供应商没有澄清,请求可以拒绝在“软件代理完全按照设计”。

换句话说,存在CVE ID应该少依赖一个全面的理论,什么是一个漏洞,而更取决于判断ID是否会帮助现实中的组织与风险管理。CNA这需要更多的工作,但让CVE更有用的100%与100%的接受或拒绝的选择。

比如KeePass 2拒绝修复其HTTP更新检查,因为它将花费开发人员广告收入:

http://www.engadget.com/2016/06/04/keepass-wont-fix-security-hole-due-to-ads/

所以我们不仅有一个已知的安全漏洞,但是我们有一个供应商严词拒绝修复它,现在我要承担KeePass2用户想知道这一点,而且我发现它不可能的供应商将会通知他们。作为这样一个CVE(产生传播的脆弱性管理服务)是一个更好的方法来确保人们得到通知。

问候,

CVE团队

- - -

- - -
Kurt Seifried——红帽产品安全——云
PGP A90B F995 7350 148 f 66高炉7554 160 d 4553 5 e26 7993
红帽产品安全联系: secalert@redhat.com