GitHub 封禁发布 Windows 零日漏洞的安全研究人员：一场关于透明度与报复的争议

背景

近期，Windows 安全领域发生了一起备受瞩目的戏剧性事件。安全研究人员 Nightmare-Eclipse（又名 Chaotic Eclipse）与微软（Microsoft）之间爆发了激烈的冲突。微软以未明确说明的理由封禁了 Eclipse 在 GitHub 上的账户，迫使其迁移至 GitLab。此外，据报道，微软还删除了 Eclipse 用于报告漏洞的 Microsoft 账户。

这一事件并非孤立发生。自今年 4 月初 Eclipse 未经警告发布名为 BlueHammer 的零日漏洞以来，双方就陷入了长期的拉锯战。Eclipse 在博客中指控微软采取报复性行动，声称微软拒绝与其沟通，且未支付其通过 MSRC（微软安全响应中心）项目应得的漏洞赏金。作为拥有六项零日漏洞发现记录的研究人员，Eclipse 威胁称 7 月 14 日将是微软的“清算日”，暗示将发布更多零日漏洞。

核心内容

冲突升级：从漏洞披露到账户封禁

Eclipse 与微软的矛盾核心在于漏洞披露流程中的沟通破裂与赏金支付问题。Eclipse 声称，微软不仅忽视了其提交的零日漏洞报告，还拒绝支付请求的赏金，导致其遭受经济损失。Eclipse 在博客中写道：“[微软] 亲自告诉我他们将毁掉我的生活，而且他们确实做到了。”他甚至提到存在某种“死手开关”（dead-man switch），并扬言要让微软的“骨头粉碎”。

微软方面对此保持沉默，未对具体情况发表评论。这种沉默加剧了外界对微软处理方式的质疑。安全专家 William Dormann 指出，MSRC 曾经以良好的合作体验著称，但为了节省成本，微软解雇了熟练人员，留下了只会按流程办事的员工。他推测，微软可能在 Eclipse 拒绝提交漏洞演示视频（据称是 MSRC 的新要求）后关闭了案例，从而引发了后续冲突。

Eclipse 的技术记录与威胁

Eclipse 在安全圈拥有令人印象深刻的技术履历，近期发布了多个针对 Windows 的高危零日漏洞：

• BlueHammer 和 RedSun：利用 Defender 获取 SYSTEM 用户权限。
• UnDefend：使 Defender 离线。
• GreenPlasma：通过 CTFMon 服务获取 SYSTEM 权限。
• MiniPlasma：通过 Windows Cloud Filter 驱动程序的缺陷获取类似权限。
• YellowKey：BitLocker 漏洞，允许攻击者几乎不费吹灰之力地打开加密驱动器，这正是该技术旨在防止的行为。

其中，BlueHammer、RedSun 和 UnDefend 已被证实正在被野外主动利用。由于 Eclipse 发布了完整或部分概念验证代码，其他漏洞被利用的可能性也极高。

社区反应与专家观点

这一事件在 Hacker News 等社区引发了广泛讨论。许多用户认为，GitHub 封禁研究人员是一种不当行为，不仅无法阻止漏洞信息的传播，反而可能激励研究人员寻找更具破坏性的零日漏洞。

• 关于 AI 与安全：有评论指出，AI 驱动的安全研究使得传统的 90 天披露-修补窗口变得过时，利用时间窗口已接近零。微软等软件厂商需要调整其政策以适应这一现实。
• 对微软官僚主义的批评：评论员 DS426 指出，微软庞大的层级结构和僵化的政策使其在舆论处理上失控。另一位用户 SmokyBarnable 则批评了科技行业中资深人员对新手的不尊重，以及 AI 对初级岗位的替代效应。
• 日期象征意义：值得注意的是，7 月 14 日恰逢 7 月份的 Patch Tuesday（补丁星期二），这被解读为 Eclipse 选择该日期发布漏洞具有强烈的象征意义和报复意图。

关键要点

• GitHub 封禁行动：微软封禁了安全研究人员 Nightmare-Eclipse 的 GitHub 账户，并删除了其用于报告漏洞的 Microsoft 账户，迫使其迁移至 GitLab。
• 报复性指控：Eclipse 指控微软因未支付 MSRC 赏金及拒绝沟通而采取报复行动，并威胁在 7 月 14 日发布更多零日漏洞。
• 微软的沉默与官僚主义：微软未公开回应细节，专家 William Dormann 认为这是 MSRC 人员变动和流程僵化导致的沟通失败。
• 高危漏洞已泄露：Eclipse 发布的多个零日漏洞（如 BlueHammer, RedSun, UnDefend, YellowKey）已被证实或极有可能在野外被利用，代码已公开，封禁账户无法阻止漏洞扩散。
• 行业反思：事件凸显了传统漏洞披露流程在 AI 时代和快速利用环境下的失效，呼吁软件厂商调整政策，而非采取对抗性措施。
• 社区强烈批评：安全社区普遍认为 GitHub 封禁行为适得其反，损害了微软的公众形象，并可能加剧安全研究人员与厂商之间的对立。

意义与影响

对安全生态系统的负面影响

GitHub 封禁安全研究人员的举动产生了严重的负面舆论效应（poor optics）。在安全领域，透明度和合作是基石。通过平台权力惩罚披露漏洞的研究人员，不仅无法阻止漏洞信息的传播（因为代码和概念验证已经公开），反而可能将原本可能私下沟通的研究人员推向公开对抗的道路。这种“封禁”策略在数字时代显得过时且无效，因为它无法控制信息的流动，只会加剧不信任。

漏洞赏金与披露政策的危机

Eclipse 的案例揭示了当前漏洞赏金计划（Bug Bounty Programs）中存在的结构性问题。当研究人员感到被忽视、未获报酬或遭受不公正对待时，他们可能会选择公开披露漏洞以施加压力。微软 MSRC 被指从“优秀”转变为“流程导向”，这可能反映了大型科技公司为了控制成本而牺牲了安全合作的质量。如果厂商不能建立公平、透明的赏金支付和沟通机制，将导致更多类似 Eclipse 的“愤怒研究者”出现，增加零日漏洞在野外的风险。

AI 时代安全研究的范式转变

文章指出，AI 驱动的安全研究正在改变游戏规则。传统的 90 天披露窗口在 AI 加速漏洞发现和利用的背景下已变得过时。利用时间（time-until-exploit）和未利用漏洞的存量都在急剧减少。微软等厂商必须认识到，依靠传统的、缓慢的官僚流程来处理漏洞已不再可行。他们需要调整政策，采用更快速、更灵活的响应机制，以适应 AI 时代的安全威胁态势。

平台中立性与权力边界

GitHub 作为代码托管平台，其封禁行为引发了关于平台权力边界的讨论。评论员指出，一家公司不应被允许控制如此多的服务。当 GitHub 成为微软打击研究人员的工具时，它削弱了自身作为中立技术社区基础设施的信誉。这一事件提醒所有平台，在处理涉及安全研究人员的争议时，需要更加谨慎，避免卷入厂商与研究人员的纠纷，以免损害社区的信任。

未来展望

随着 7 月 14 日 Patch Tuesday 的临近，安全社区预计将看到更多来自 Eclipse 或其他类似研究人员的行动。这一事件将成为一个警示案例，促使微软和其他软件厂商重新审视其与外部安全研究人员的互动方式。如果厂商继续采取对抗性措施，而非建设性对话，未来可能会面临更频繁、更公开的零日漏洞披露，从而增加整个生态系统的安全风险。