再保险:通过CVE申请表有问题的作业为低于标准的报告

这就是为什么我认真考虑做一份所有CVE提交材料一个强制性的任务的一部分(如任何web页面的快照)。我认为我们应该重新审视这个问题,尤其是在垂死的所有url。

在星期一,2017年11月13日,在早上7:30,帕斯卡莫尼耶<pmeunier@cerias.purdue.edu>写道:

这类事件削弱了CVE的基础。在之前的板
电话,我们讨论了引用的问题,随着时间的推移,由于消失
衰老和遗弃。都是用例,证明尝试
归档CVE引用。

帕斯卡

星期一,2017-11-13 00:12 + 0100,Carsten Eiram写道:
>快速后续讨论,今天我发现,林
>王
>看似2017/10/31删除他所有的报告:
>https://github.com/wlinzi/security_advisories /提交/d571e1c1e2829483
> 3 a96a070b494a7eeeb6fd516
>
>除非我忽略了什么都是空白的例句:
>https://github.com/wlinzi/security_advisories /树/主/ cve - 2017 - 14所示
> 302
>
>自然,我们不能保证或期望为脆弱性报告
>存在
>无限期,但奇怪的是当删除后不久
>出版于
他们可以在>的唯一来源。除非这是一些错误,
>看着他Github库似乎他原因未知
>决定清理整个存储库,以防止读旧的
>报告和把空白假条目。也许他
>突然
>质疑他的报告的质量/有效性。
>
>我认为这增加了为什么分配cf对他的任何报告
>前锋应该是一个问题。他们中的许多人一开始就有问题
>与
>,现在也被删除了,这是一个问题,因为他们
>唯一
>中引用来源分配cf。我们现在有330 cf
> 2017
>与死去的引用从一个不可靠的脆弱性
>发现者。
>,除非他打算重新发布的信息,这使得第三方
>审查
>更加困难。如果cf分配给他的任何未来的报告,我们
>应该
>至少考虑捕获公开这些其他的副本。
>
> / Carsten
>
>
>在星期五,2017年11月3日下午5:06,棺材,克里斯<ccoffin@mitre.org>
>写道:
>
> > Carsten,
> >
> >
> >
> >下面是一些答案在你的编号和思想问题。
> >
> >
> >

> > - 1)基于以上,看来斜方已经有了一些
> >过程具有挑战性的脆弱性记者。你能
> >请详细说明
> >当前进程?
> >
> > CVE分析师CVE ID分配代表横切
> > CNA有
> >多年的脆弱性分析和使用经验
> >耦合
> >与当前CVE计数规则,以确定一个CVE ID
> >应该
> >。这个角色的CVE分析师能够检测数百人
> >的
> >不同的场景的提交并不“提供
> >了
> >错误”(CNT2.2A)产生负面影响。一个简单的循序渐进
> >清单
> >不存在这个过程。
> >
> >
> >
> > - 2)是什么让王斜方决定挑战林提供

> >证明在某些情况下吗?我提出这个问题之前,
> >有
> >,表明任何横切持怀疑态度的cf分配给林
王> >;甚至
> >第一反应横切只字未提。
> >
> >分析师想知道崩溃是否产生负面影响
> >的
> >产品的用例,也想知道具体
> >文件类型
> >可以提交给产品的方式交叉特权
> >边界。
> >
> >
> >
> >为例,我们不会分配一个CVE ID为“良性的崩溃”
> >命令行程序,是为了读一个图像文件,做的
> >的东西
> >,然后停止执行。如果一个产品不仅限于
该类型> >
> >命令行用法,是一个长时间运行的桌面
> >应用程序,
> >那是可能的,所有的崩溃(任何原因)
> >
> >负面或消极的机密性影响可用性的影响
> >(或
> >)。也有可能不同的长时间运行的桌面
> >应用程序,如果它有足够的有限使用情况下,不会
> >是
> >描述为脆弱的基础上“良性崩溃。”
> >
> >
> >
> >林王也给我们报道成为DLL文件
> >通过cve cve - 2017 - 15790 - 2017 - 15803。我们最初的挑战
> >的
> >因为信息不足之间的交互
> >基础
> >产品和DLL文件。例如,它不是一个漏洞
> >
> >威胁模型是一个攻击者,他已经选择的能力
> >什么代码
> >中存在一个DLL文件,然后导致产品执行代码
> >,
> > DLL文件。林王告诉我们,DLL文件的威胁模型
> >一样的
> >作为任何类型的图像文件的威胁模型,因为该产品
> >只是
> >试图呈现一个图标图片中包含的DLL文件。
> >
> >
> >

> >特定cf - 3)横切挑战林王吗?它是
> >好
> >听到它,但我们认为它重要的理解
> >,
> > cf额外的审查是由斜方。
> >
> >看到之前的答案。
> >
> >
> >
> > - 4)那是林王又提供了哪些具体细节
> >被认为
> > CVE作业的理由吗?我相信poc的
> >措辞。如果
> >所以,事实是,poc提供所有必需的
> >或的
他们测试和事故分析> >程度?你刚
> >确认崩溃
> >和基于考虑报告合法的更严重
> >的影响
> >可信吗?这些的确可能还是时间确定
> >有一个
> >更严重的推测(随机猜测)的影响
> >脆弱性
> >记者?
> >
> >提供了PoC私下在每一情况下。这是
> >在
> >每个案例的CVE PoC的其他并不相同
> > CVE。
> >
> >
> >
> >
> >
> >克里斯
> >
> >
> >
> > *:* Carsten Eiram [mailto:che@riskbasedsecurity。com]
> > *发送:*周二,2017年10月31日,40分
> > *:*棺材,克里斯<ccoffin@mitre.org>
马尼恩艺术> > * Cc: * <amanion@cert.org>;cve-editorial-board-list <
> >cve-editorial-board-list@lists.mitre.org>
> > *主题:* Re:问题通过CVE作业为低于标准的报告

> >请求
> >形式
> >
> >
> >
> >在星期四,2017年10月26日下午3:36,棺材,克里斯<ccoffin@mitre.org>
> >中写道:
> >
> > Carsten,
> >
> >
> >
> >在回答具体的CVE IDs横切CNA的分配
林> >
> > Wang CVE ID分配的理由往往取决于非
> >公共
> >信息。它可以是,但并非总是,一个非公有制PoC。在那里
> >有
> >也是我们要求林提供的情况
> >的理由
> >他的漏洞。在每种情况下他提供了理由
> >。林是否让这些额外信息
> >大众
> >是他。也许我们可以推动林提供更多
> >信息
> >(包括poc)将来一旦漏洞
> >固定的
> >供应商。
> >
> >
> >
> >
> >
> >我知道横切有时收到额外的细节
> >,
> >这是好的。然而,我也有信心基于我们的分析
> >这
> >特殊脆弱性记者不能够
> >提供斜方
> >与任何其他细节或poc的这些问题
> >将
> >证明CVE作业。这是明显的崩溃报告
> >,
> > VulnDB我们进行了额外的分析。
> >
> >
> >
林> >讨论王一直关注它的目的
> >
> >大,潜在的问题。我不会花更多的时间讨论
> >他
> >。我们有证据表明CVE作业有关
> >他的很多
> >报告是无效的,而斜方似乎整体考虑
> >好。在那里
> >是没有理由进一步讨论。
> >
> >
> >
> >相反,请反馈以下问题相关的
> >
> >:
> >
> >
> >
> > 1)基于上述,看来斜方已经有了一些
> >的过程
> >挑战弱点记者。你能详细说明吗
> >
> >当前过程?
> >
> >
> >
> > 2)是什么让王斜方决定挑战林提供
> >的理由
> >在某些情况下吗?我提出这个问题之前,没有什么
> >
> >显示斜方持怀疑态度的分配cf林王;即使是
> >非常
> >第一反应从斜方没有提及它。
> >
> >
> >
> > 3)特定的cf横切挑战林王吗?它是好的
> >听
> >这是做的,但是我们考虑的理解很重要
> > cf
> >额外的审查是由斜方。
> >
> >
> >
> > 4)林王又提供了哪些具体细节,被认为是
> > CVE作业的理由吗?我相信poc的
> >措辞。如果
> >所以,事实是,poc提供所有必需的或
> >,
他们测试和事故分析> >程度?你刚才确认
> >崩溃
> >和基于考虑报告合法的更严重
> >的影响
> >可信吗?这些的确可能还是时间确定
> >有一个
> >更严重的推测(随机猜测)的影响
> >脆弱性
> >记者?
> >
> >
> >
> >
> >
> >
> >
> > CVE团队已经能够挑选出以下的列表
> >单独
> >在这个线程问题和问题。它可以帮助如果我们分开
> >,
> >分别讨论它们。
> >
> > 1。我们应该禁止请求者当他们一再提供吗
> >当请求CVE ID可疑漏洞细节?
> >

> > 1。主教法冠将与董事会决定前进的道路
> >。
> >的一个担忧是,禁止请求者完全可能
> >发送一个
> >负面消息一般社区和可能
> >我们
> >应该避免。
> > 2。做其他董事会成员认为禁止请求者是

> >合适,或者我们应该给他们更多的压力
> >证明他们的
当这些情况下出现> >工作?
> >
> >
> >
> >我的观点是,最初CNA应该要求更多的信息
> >,
> >证明在处理报告,被认为是可疑的。
> >的关键
> >就能发现这样的报道。如果漏洞
> >记者
> >无法或拒绝提供更多信息,没有CVE应该
> >分配
> >的具体问题。如果相同的漏洞的记者
> >未来
> > cf请求额外的问题报告和仍然失败
> >
> >提供足够的信息,将被提出
> >讨论
> >被禁止。
> >
> >
> >
> >在这种情况下,这个过程将确保中央社
> >即将到来
> >,并试图与脆弱性的记者,但无济于事。
> >在
> >有些漏洞记者抱怨,我肯定更大
> >社区
> >——更重要的是CVE消费者会很感激和视图
> >
> >过程公平。
> >
> >
> >
> >如果CVE宁愿避免激怒一些羽毛和分配cf
> >
> >问题甚至明显无效的报告,然后
> >的可信度
> > CVE id是玷污。我们坚信,CVE应该关注
> >
> > CVE消费者的利益;不是漏洞记者,人
> >在
> >标识为惯犯,只是想要尽可能多的cf
> >可能系
> >他们的名字没有作出努力。
> >
> >
> >
> >
> >
> > 2。我们应该如何处理研究人员喜欢王林在未来吗?
> >
> >
> >
> >如果林“研究人员喜欢王”指的是不可靠的脆弱性
> >记者报道有问题缺乏足够的信息,
> >我想
> >某种类型的限制是必需的。我也建议斜接
> >会做
> >投资和帮助教育质量问题的记者
> >
> >继续他们的研究,并提供有价值的工作。
> >
> >
> >
> >
> >
> >

> > 1。可能是个更好的前进道路,建议和旗帜
> >
> >请求者用于将来的请求。也许我们可以发展
> >一些简单的
> >过程必须在附加信息或细节
> >可能
> >要求在这些情况下。如果请求者被标记,一个中央社
> >如主教法冠
> >可以将请求并要求略有不同
> >更多
> >如PoC的信息。这可能会导致额外的工作
> >的部分
> > CNA的,但假设是这种情况下不会
> >标准
> >不会经常发生。除了这个过程中,我们必须
> >定义
> >参数当国旗请求者,和是什么
> >要求
> >他们国旗移除。
> > 2。其他可能需要的人有什么建议

> >
> >请求者在这些情况下吗?
> >
> >
> >
> >只要愿望是验证是正确完成,
> >然后
> >这个方法听起来不错。我同意这一点
> >应该
> >只影响很少脆弱性记者。因此,额外的
> >工作
> >应该是最小的。
> >
> >
> >
> > CNA的目标不是也不应该去做研究
> >代表
> >脆弱性的记者,而是双重检查有效性
> >的
> >报告基于现有信息。如PoC应该提供吗
> >,
> >快速测试并不意味着比良性崩溃产生影响,
> >了
> >脆弱性记者做出更好的工作。他或她
> >,
> >证明范围内的问题,而不只是猜测”或
> >可能
> >未指明的其他影响”林王。
> >
> >
> >
> >还我认为重要的是要考虑在国旗cf
> >,
> >被分配根据CNA额外的审查。这种方式
> >其他CNAs
> >和CVE消费者知道执行额外的审查。
> >甚至
> >包括评论这审查是如“PoC提供什么
> >私下
> >和崩溃展示缓冲区溢位验证。“这将
> >的信号
> >即使报告似乎有问题,进一步分析
> >有
> >,可以信任的CVE ID。
> >
> >
> >
> >
> >
> > 3。斜接的入选标准是什么弱点。
> >

> > 1。斜方目前使用CNT2.2A作为标准的一部分

> >确定
> >是一个脆弱的东西。当规则,提出了
> >
> >讨论这样的问题研究员在哪里
> >声称
> >漏洞可能收到可疑的人。
> >
> >的共识是,这些作业将可以接受这么长时间
> >
> >补救措施争端,拒绝。如果
> >板没有
> >再感觉CNT2.2A是决定是否有效的标准
> >是一个东西
> >的弱点,然后可能需要讨论关于
> >只使用
> > CNT2.2B。
> >
> >
> >
> >我认为这种方法是CVE消费者的一种伤害。很好
> >你
> >建议我们重新讨论。这将导致组织
> >浪费
> >时间问题那么严重或完全无效。
> >等
> >作业应该保持在合理的数量减到最少
> >的
> >工作。
> >
> >
> >
> >如前所述,我不认为这是CVE瞄准的目标
> >在
> > 100%的准确率,但一些审查应该执行清除
> >问题很明显无效的请求。这是有问题的
> > cf是
> >分配给请求(老实说“幼稚”)这样的希望
> >一个人
> >其他争议/拒绝它如果是错误的。这变得更
> >问题
> >时,甚至没有一个公共poc至少要求
> >这样的情况下
> >让众包纠纷的可能性更大。
> >
> >
> >
> >说,即使有公共poc,我们知道人群-
> >采购
> >纠纷仍不会发生必要的程度。
> >
> >
> >
> >
> >
> > 4。社区纠纷CVE似乎并不鼓励
> >作业
> >

> > 1。正如上面提到的,使用CNT2.2A似乎可以接受

> >只要
> >纠纷/拒绝流程工作。然而,随着Carsten
> >所示,
> >那些可以用来争议或研究
> >拒绝反暴力极端主义
> >不鼓励CVE提供这些信息。做
> >这一变化
> > CNT2.2A董事会成员的感受呢?
> >
> >
> >
> >评论在以前的响应,这只适用(甚至
> >不
> >真的)的时候到处CVE;不是很大的时候
> >块
> >的cf。CVE请求表单生成的新方法
> >太多
> >。我们不应该期望众包的方法
> >纠纷/拒绝
> > cf。没有任何价值的人花时间
> >。
> >脆弱性记者正在关注如何请求
> >最cf
> >为自己的发现;包括bug赏金赚钱;
> >不是“浪费
> >时间”争论的结果。
> >
> >
> >
> >极几CVE消费者,花资源来验证
> > CVE
> >作业,不会经历整个纠纷的过程
> >,
> >提供足够的证据。事实上,目前似乎太多了
> >更多
> >为了争端CVE比请求。这是值得
> >思考。
> >
> >
> >
> >
> >
> > 5。防止重复
> >

> > 1。重复的评论在很大程度上与一些赤字

> >,
> >中存在CNT1(独立可以解决的)。特别是,CNT1
> >不
> >提供指导如何处理情况有一些
> >的证据
> >这两个问题是一样的脆弱,但是你不是
> >确定。主教法冠遵循的政策在这些情况下
> >分组
> >请求时使用的请求。然而,在最
> >最近规则
> >修订,我们提出了一种改变CNT1的问题
> >被合并
> >成一个单一的CVE ID是否是否存在不确定性
> >重复。变更批准和斜接
> >吗
> >。新规则应该停止这些类型的可能
> >复制
> >作业在未来。这个问题部分
> >解释说
> >为什么cve - 2017 - 15773和cve - 2017 - 15738是分开的。
> >
> >
> >
> >这是一个很好的变化。有疑问时,合并比一个好
> >分裂。我们
> >可以分裂后如果可用的更多细节(很少
> >)
> >证明它。
> >
> >
> >
> >
> >
> > 6。需要多少确定之后再做决定吗
> >分配
> > CVE ID吗?
> >

> > 1。退一步,讨论绕圈
> >
> >程度的确定性需要分配一个CVE ID。这是如何
> >确定
> >获得获得确定性的成本是什么?它是
> >值得
> >结果?
> > 2。Carsten:你使用了什么过程来确定cve - 2017

> > 15738
> >和cve - 2017 - 15773是重复的?花了多长时间?
> >
> >
> >
> >我只是看着事故提供了一个输出
> >报告和
> >相比其他具有类似特征。很明显
> >很
> >立即处理其中一个时,它可能是
> >复制
> >。我双重检查后怀疑
> >拆卸
> >影响图书馆的两个产品。标准的做法
> >我们
> >真的;不需要华丽的或复杂的过程。
> >
> >
> >
> >很难说花多长时间,因为它是一个更大的一部分
> >流程
> >无效块分配cf的很大一部分。这是
为VulnDB > >是我们经常做的,所以我们说的只有少数
> >分钟,
> >。如果我只是需要失效这一问题,它将
> >有
> >花了很长时间来下载并安装两个产品比现货
> >受骗的人
> >并打开库确认。在某些情况下,可能需要
> >,
> >但熟悉验证漏洞应该报告
> >可以
> >执行这种类型的审查在很短的时间内。
> >
> >
> >
> > / Carsten
> >
> >
> >

- - -

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