CVE-2018–8414：负责任披露的案例研究
漏洞披露过程可能充满挫折、伦理担忧和沟通失败。我有很多漏洞报告进展顺利，也有很多进展不佳。
我通过赏金计划（Bugcrowd/HackerOne）和直接报告渠道（微软）提交了大量漏洞。我在这里不是为了讨论伦理，也不是为了给“漏洞披露”这一大辩论提供解决方案。我只是想分享一次让我印象深刻的经历，并希望它能引起所有厂商对报告流程的一些反思。
首先，我想简单介绍一下我自己以及我与漏洞研究的关系。
我不是经验丰富的逆向工程师，也不是全职开发者。我精通C/C++吗？不。我进入这个行业相对较新（3年）。我利用业余时间进行研究，弥补知识差距。我不寻找疯狂的内核内存泄漏，而是寻找经常被忽视的用户模式逻辑漏洞（比如DACL覆盖漏洞？）。
最重要的是，我将漏洞研究（VR）作为一种爱好，以学习我感兴趣的技术概念，这些概念不一定直接适用于我的日常工作。尽管经验有限，但我在VR中的经历与其他人一样充满痛苦。
当我报告漏洞时，过程通常如下：
- 发现漏洞 -> 披露漏洞 -> 厂商对漏洞睁大眼睛 -> 漏洞被修复，可能发布CVE（附带相关致谢）-> 案例关闭
- 发现漏洞 -> 披露漏洞 -> 厂商未能看到影响，发布“不予修复” -> 案例关闭
在审视这两种情况时，有多种因素可以决定你的报告属于第1种还是第2种。这些因素可能包括：
- 厂商内部政治/重组
- 案例处理人员的经验/职业道德/沟通（!!!!）
- 报告质量（你是否很好地解释了漏洞，并概述了漏洞对产品的影响？）
当你无法控制的因素反复出现时，它们会开始引起挫折感。这时，厂商需要对其流程持开放态度，接受反馈，而研究人员也需要对其报告持开放态度，接受反馈。
那么，让我们来看一个漏洞报告出错的案例研究（随后得到纠正）：
2018年2月16日下午2:37，我向secure@microsoft.com发送了一封电子邮件，其中包含Windows 10中.SettingContent-ms文件格式的远程代码执行（RCE）漏洞的详细说明和概念验证（PoC）。以下是原始电子邮件的内容：
这种情况是研究人员需要接受反馈的一个好例子。回顾我最初的提交，我主要围绕Office 2016的OLE阻止列表和Windows Defender中攻击面减少规则的绕过框架了漏洞。然而，我在电子邮件中提到了“PoC压缩包包含武器化的.settingcontent-ms文件（允许从互联网执行代码，且用户无安全警告）”。这是非常重要的一行，但它被电子邮件的其余部分掩盖了。
2018年2月16日下午4:34，我收到了微软的模板回复，称已分配案例编号。我的理解是，当案例处理人员接手（或被分配）你的案例时，这封电子邮件是相当自动化的：
很好。在这一点上，这只是一个等待游戏，等待他们对报告进行分类。等待一段时间后，我在2018年3月2日中午12:27收到一封电子邮件，称他们成功重现了问题：
太棒了！这意味着他们能够利用我的详细说明和PoC确认其有效性。在这一点上，许多研究人员会感到沮丧。你花时间发现漏洞，花时间报告它，几乎立即得到厂商的回应，一旦他们重现了问题，事情就变得安静了。这是可以理解的，因为他们可能正在对问题进行根本原因分析。这是决定漏洞是否值得修复的关键点。
我承认，我通常遵循Google Project Zero使用的90天政策。我不为GPZ工作，我找漏洞（或管理多个报告）也没有报酬。如果沟通存在，我倾向于宽容。如果厂商不与我沟通，我会在90天窗口关闭后的第二天发布博客文章。
厂商们，请与你们的研究人员沟通！
在这种情况下，我像许多研究人员一样，在一个多月没有任何消息后……我要求更新：
在这一点上，我已经将近一个半月没有听到任何消息。在要求更新后，这封电子邮件进来了：
有趣……我突然有另一个人处理我的案例？我可以理解这一点，因为微软是一个庞大的组织，有各种人员处理他们每天收到的大量报告。也许我的案例处理人员忙得不可开交？
让我们暂停并评估到目前为止的情况：我报告了一个漏洞。这个漏洞被分配了一个案例编号。我被告知他们重现了问题，然后我一个半月没有听到任何消息。在联系后，我发现案例被重新分配了。为什么？
厂商们，这就是引起挫折的原因。研究人员觉得他们被拖着走，被蒙在鼓里。如果你不想0day漏洞最终出现在Twitter上，沟通是关键。实际上，我们中的许多人牺牲个人时间在你们的产品中寻找漏洞。如果人们觉得他们不重要或被搁置，他们就不太可能向你们报告漏洞，更可能出售它们或在线发布。
好吧，所以我的案例在2018年4月25日中午12:42被重新分配。几天后，我说“谢谢！！”，然后让案例搁置，等待他们处理漏洞。
然后，一个多月过去了，没有任何消息。在这一点上，自从我提交原始报告以来已经超过90天。作为回应，我在2018年6月1日下午1:29发送了另一封跟进邮件：
几天后，我在2018年6月4日上午10:29收到回复：
好吧。那么，让我们从头开始。2018年2月16日，我报告了一个漏洞。在经过典型的开案和验证问题过程后，我在一段时间没有回复后随机被重新分配了一个案例处理人员。然后，在等待一段时间后，我仍然没有听到任何消息。所以，我跟进并在初始报告整整111天后得到了一个“不予修复”的回应。
我首先承认，一旦案例关闭，我不介意写博客谈论某事。毕竟，在我看来，如果厂商不在乎修复它，那么世界应该知道它。
鉴于这一回应，我于2018年7月11日继续写了博客。在我发布帖子后，很快就有另一位研究人员在Twitter上联系我，让我知道我的博客文章由于.SettingContent-ms文件格式的Mark-of-the-Web（MOTW）影响，导致了Chrome和Firefox中的0day漏洞。鉴于这一新信息，我在2018年6月14日上午9:44向MSRC发送了一封新电子邮件：
在这一点上，我看到了两个利用.SettingContent-ms文件格式影响Google Chrome和Mozilla FireFox的漏洞利用。在重新发送细节后，我在2018年6月14日上午11:05收到一封电子邮件，其中MSRC通知我案例将更新：
2018年6月26日中午12:17，我向MSRC发送了另一封电子邮件，让他们知道Mozilla由于该漏洞发布了CVE-2018-12368：
同一天，MSRC通知我，额外的细节将传递给团队：
这时事情真的发生了转变。我在2018年7月3日晚上9:52收到另一封电子邮件，称我的案例再次被重新分配，并且他们正在根据各种其他MSRC案例、Firefox CVE以及Google Chrome的待定修复重新评估案例：
这时同情心可以发挥作用。我们都只是做工作的人。虽然我经历的过程很糟糕，但我对此并不苦涩或愤怒。所以，我的回应是这样的：
一段时间后，我意识到一些犯罪软件组织正在以一些非常糟糕的方式利用这种技术（https://www.proofpoint.com/us/threat-insight/post/ta505-abusing-settingcontent-ms-within-pdf-files-distribute-flawedammyy-rat）。在看到它在野外被使用后，我让MSRC知道：
MSRC很快让我知道他们将尽快发布修复……这与原始报告评估完全相反：
此外，还提到了“另一个MSRC案例线程上的另一封电子邮件”。这 definitely 引起了我的兴趣。几天后，我收到一封奇怪的电子邮件，其案例编号与最初分配的不同：
在这一点上，我惊呆了。在向一个已关闭的MSRC案例发送一些额外信息后，漏洞从“不予修复”变成了“我们将尽快发布修复，并奖励你赏金”。在与微软赏金团队进行一些次要的后勤交流后，我看到CVE-2018-8414在cve.mitre.org上获得了一席之地。这非常有趣，因为不到一个月前，这个问题还处于“不予修复”状态。所以，我向MSRC询问了此事：
这时我很快发现CVE-2018-8414是为.SettingContent-ms RCE漏洞发布的：
这时过程变得很酷。之前，我披露了一个漏洞。那个漏洞被给予了“不予修复”状态。所以，我写了博客（https://posts.specterops.io/the-tale-of-settingcontent-ms-files-f1ea253e4d39）。然后我发现它被用来利用两个浏览器，并且在野外被使用。我没有让事情搁置，而是主动与MSRC联系，让他们知道所有这些。一旦8月的补丁星期二到来，我收到了这封电子邮件：
耶！！！所以微软根据我提供的