再保险:关于CVE作业oss-sec邮件列表

2015年12月结婚,9日上午37,埃文斯,乔纳森·L。<jevans@mitre.org>写道:

马克,

我们一直积极与上游供应商合作,确定适当数量的cf git的漏洞。没有oss-security横切的横切,因为上下文的之前的工作与私人通信和上游供应商。

初始请求中的信息(http://seclists.org/oss-sec/2015/q4/37)要求我们推断的漏洞代码差别和模糊的更新日志语句。从历史上看,基于CVE作业这种类型的信息被证明是困难和容易出错。例如,我们不知道在库尔特的转让cve - 2015 - 7545“一些协议(如git-remote-ext)可以执行任意代码中发现URL”是正确的。供应商可能没有正式支持“盲目使递归获取”场景,即用户预计将接受的风险执行递归获取一个不可信的来源,和改变应该考虑安全硬化特性为方便用户。在这些情况下斜方依赖于供应商的指导。

在未来,我们打算像最初的一个快速响应请求,要求请求方所需的适当的信息分配一个CVE ID。如果编辑委员会成员建议更好的方法来处理这些情况,我们将不胜感激你的输入。

- - -
乔纳森埃文斯
CVE团队
manbetx客户端首页

当我靠不住的CVE请求/安全报告我通常要求更多的信息,这显然是一个更容易与开源(请发送我的链接代码更改/你能解释一下这个源代码做/等等)。一些请求(如fuzzer)我只是往后推,需要有效的,最小化测试用例与解释(在一个案例中有人发送~ 100例发行版,要求澄清,说回来之后没有可利用的超出当地崩溃在命令行文件转换应用,所以不是CVE值得)。我通常目标1营业日回复和理想情况下实际的CVE任务,这是延迟关闭循环的一个重要的组成部分,尤其是在记忆衰减在人们快速(问我关于一个星期从现在开始,我得花点时间重新获得上下文)。

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