CVE-2018–8414：负责任披露案例研究
漏洞披露过程可能充满挫折、道德顾虑和沟通失败。我经历过许多顺利的漏洞报告，也经历过许多糟糕的情况。
我通过漏洞赏金计划（Bugcrowd/HackerOne）和直接报告渠道（微软）提交了大量漏洞。本文不讨论道德问题，也不为“漏洞披露”争论提供解决方案，仅分享一次令我印象深刻的经历，希望引起所有厂商对报告流程的反思。
背景介绍
我并非经验丰富的逆向工程师，也不是全职开发人员。我入行仅三年，利用业余时间进行研究以弥补知识缺口。我发现的通常是容易被忽略的用户模式逻辑漏洞（例如DACL覆盖漏洞）。
典型漏洞报告流程
- 发现漏洞→披露漏洞→厂商高度重视→漏洞修复并可能分配CVE编号（附致谢）→案例关闭
- 发现漏洞→披露漏洞→厂商未能认识影响→判定“不予修复”→案例关闭
案例时间线
2018年2月16日：向secure@microsoft.com提交.SettingContent-ms文件格式的RCE漏洞报告及PoC。原始邮件主要围绕Office 2016 OLE阻止列表和Windows Defender攻击面减少规则绕过展开，但提及“PoC压缩包包含武器化的.settingcontent-ms文件（可实现从互联网无安全警告执行代码）”。
2018年3月2日：微软确认复现漏洞。
2018年4月25日：案例被重新分配处理人员。
2018年6月4日（报告后第111天）：收到“不予修复”决定。
2018年7月11日：公开发布博客文章披露漏洞。随后有研究人员指出该漏洞因Mark-of-the-Web（MOTW）问题导致Chrome和Firefox存在0day。
2018年6月14日：向MSRC提交新证据，包括浏览器漏洞详情。
2018年6月26日：告知MSRC Mozilla已分配CVE-2018-12368。
2018年7月23日：发现犯罪组织正在野外利用该技术。
2018年7月27日：MSRC宣布将尽快发布补丁并授予赏金。
2018年8月14日：补丁正式发布。
2018年9月28日：获得15,000美元赏金。
经验总结
- 展示漏洞最大危害：原始报告过于侧重Office和Windows Defender功能绕过，未突出RCE影响。
- 沟通至关重要：厂商应主动向研究人员提供进度更新，避免让研究者感到被忽视。
- 坚持跟进：若认为漏洞被误判，应补充新证据（如野外利用情况）推动重新评估。
时间线摘要
- 2018.02.16 提交报告
- 2018.03.02 漏洞复现确认
- 2018.06.04 判定“不予修复”
- 2018.07.11 公开披露
- 2018.07.27 决定修复并授予赏金
- 2018.08.14 补丁发布
- 2018.09.28 赏金到账
漏洞披露始终是复杂难题，需要厂商与研究人员相互尊重、保持透明，共同提升网络安全。