漏洞赏金计划的困境：i915漏洞与ChromeOS、Intel赏金项目剖析

最初，我并未计划撰写关于漏洞赏金计划问题的文章。这原本应该是一篇标准的技术博客，描述Linux内核i915驱动中一个有趣的漏洞，该漏洞允许线性越界读写访问（CVE-2023-28410）。而且，我甚至并不热衷于漏洞赏金计划，主要是因为我不需要——我认为自己很幸运，拥有一份满意、稳定且收入丰厚的工作。

尽管如此，在我的业余时间，除了开发和维护Linux内核运行时防护（LKRG）项目外，我仍然喜欢进行漏洞研究和漏洞开发，不仅为我的雇主工作，偶尔用新的CVE编号更新简历也是好事。在我开始有稳定收入之前，漏洞赏金并不存在，大多数高质量的漏洞研究成果通过经纪人支付账单（让我们暂且搁置由此产生的道德问题）。然而，如今我们有了漏洞赏金计划……

漏洞赏金计划的历史背景

在过去的十年（稍长一些）中，漏洞赏金计划获得了应有的关注。有些安全研究人员依靠漏洞赏金作为他们的主要收入来源。这些情况无可辩驳地证明了漏洞赏金计划的成功。然而，在行业发展到今天这个状态之前，它经历了一条漫长而有趣的道路。

早期漏洞披露运动

• 1993年11月5日，Scott Chasin创建了bugtraq邮件列表，以回应CERT的问题，安全研究人员可以在其中发布漏洞，无论供应商如何回应，作为漏洞披露的完全披露运动的一部分。
• 2002年7月9日，Len Rose创建了Full Disclosure——一个"轻度审核"的安全邮件列表，因为许多人觉得bugtraq邮件列表"变得更糟了"。

然而，并非所有人都同意"完全披露"哲学，两种主要的替代方案可以概括为不披露和协调披露（也称为"负责任披露"）。不披露通常受到黑帽黑客以及后来的商业漏洞供应商（包括经纪人）的青睐。

协调（负责任）漏洞披露是一项政策，研究人员同意向协调机构报告漏洞，然后该机构将其报告给供应商，跟踪修复和缓解措施，并与包括公众在内的利益相关者协调信息披露。在某些情况下，协调机构是供应商本身。

然而，一些研究人员开始对供应商如何处理报告的漏洞（并将研究人员视为敌人）表示担忧，而其他人则开始期望对其报告获得补偿（类似漏洞赏金计划）。

“不再免费提供漏洞”

2009年3月，在CanSecWest会议上，Alex Sotirov、Dino Dai Zovi和Charlie Miller宣布了"不再免费提供漏洞"运动，传播了在大多数情况下他们将不再向供应商免费提供漏洞通知的信息。无论其效果如何（实际上并不太有效），这无疑成为了行业新闻，并开启了关于该问题的更广泛辩论。

值得一提的是，在过去，当安全研究人员因工作获得免费T恤时，他们可以认为自己很幸运。真正的回报来自声誉和第三方的职位邀请（如果有的话）。

我提到所有这些"过去的问题"是因为它们是今天我们以某种形式拥有漏洞赏金计划的基础和原因。而且，我们当然不希望行业回到过去的状态。

漏洞赏金计划——一个美好的新世界！

漏洞赏金计划起源于互联网早期，Netscape和Mozilla等公司为其软件中发现和报告安全漏洞提供奖励。“漏洞赏金"的概念在2000年代初由美国国防部通过启动漏洞奖励计划（VRP）正式确定。从那时起，许多技术公司和组织实施了类似计划，为发现和报告其系统中漏洞的安全研究人员提供奖励。

这些计划已成为打击网络犯罪的重要工具，因为它们激励个人在恶意行为者利用漏洞之前发现并报告漏洞。

然而，有些人可能会问"为什么公司要费心创建漏洞赏金计划？“这是一个合理的问题，从公司的角度来看，向"随机"人员支付金钱以在其产品中查找漏洞有什么意义？漏洞赏金不仅使研究人员受益。事实上，如果公司的安全性足够成熟，并且他们的产品开发是安全导向的（通常情况并非如此），它们实际上可以带来很多好处，包括：

• 成本效益高的漏洞管理——漏洞赏金可能比聘请第三方安全公司进行渗透测试或漏洞评估更具成本效益（特别是对于非常复杂和成熟的产品）。此外，通过漏洞赏金计划，公司可以扩大其测试和漏洞研究覆盖范围，因为他们可以拥有许多具有不同专业水平、经验和技能的安全研究人员测试他们的产品和系统。这可以帮助公司找到可能被内部团队遗漏的漏洞。
• 品牌声誉——通过拥有漏洞赏金计划，公司可以表明他们关心安全并愿意投资于安全。它还可以帮助提高公司在安全行业的声誉。
• 保护品牌——通过开放漏洞赏金计划，公司可以鼓励研究人员直接向他们报告漏洞，而不是公开披露或将其出售给恶意行为者。这有助于缓解各种安全风险。
• 向潜在客户做广告——漏洞赏金表明他们认真对待安全，并积极努力识别和解决漏洞。公司可以与客户、合作伙伴和其他利益相关者建立信任。

然而，应该指出的是，拥有漏洞赏金计划并不能替代安全SDLC、定期安全测试和漏洞管理实践等的需求。它是一个额外的安全层，可以补充现有的安全措施。

“漏洞赏金计划已损坏”

正如我们所看到的，漏洞赏金非常成功，因为双方——研究人员和公司——都从中受益。然而，尽管如此，近年来越来越多的安全研究人员开始大声抱怨一些特定的赏金计划。几年前，考虑到漏洞赏金的成功，这种不利意见是边缘化的。当然，它们一直存在，但肯定不像现在这样明显。每当一家新公司加入开放漏洞赏金的革命时，他们都会受到（尤其是媒体的）赞扬，因为他们成熟并理解安全问题的重要性，而不是假装安全问题不影响他们。然而，是否有任何媒体文章真正详细分析了这些计划的运作方式？计划条件中真的没有为研究人员隐藏陷阱吗？

不幸的是，似乎每个月社交媒体（Twitter？）都会讨论一些公司围绕其漏洞赏金计划的，委婉地说，有争议的活动。漏洞赏金的黄金时代结束了吗？也许除了更多研究人员开始依赖漏洞赏金作为他们主要（或重要）收入来源之外，变化不大。自然，漏洞赏金的问题会显著影响他们的生活，并导致他们更广泛/大胆地提出担忧。

漏洞赏金（以及任何类型的漏洞报告计划）总是涉及研究人员的风险。一些主要原因包括：

1. 奖励不足——一些研究人员可能觉得漏洞赏金计划提供的奖励不足，无论是货币价值还是他们获得的认可。对于发现高严重性漏洞的研究人员来说尤其如此，这些漏洞可能更难或更耗时才能找到。
2. 沟通缓慢或不回应——研究人员可能会对漏洞赏金计划协调员缓慢或不回应的沟通感到沮丧，特别是在分类和处理报告的漏洞时。
3. 缺乏透明度——研究人员可能觉得漏洞赏金计划的运行方式和奖励确定方式缺乏透明度。他们可能还觉得关于哪些漏洞正在修复以及何时修复缺乏沟通。
4. 范围不明确——研究人员可能觉得漏洞赏金计划的范围没有明确定义，使他们难以知道哪些漏洞在范围内，哪些不在。
5. 重复报告——当研究人员报告一个漏洞，然后发现它已经被其他人报告时，他们可能会感到沮丧。如果他们因工作没有得到奖励，这尤其令人沮丧。
6. 拒绝报告——研究人员可能觉得他们的报告在没有明确解释的情况下被拒绝，或者他们的报告不被视为漏洞。
7. 没有公开认可——一些研究人员可能希望他们的工作得到公开认可，而不仅仅是金钱奖励。

正如您可以想象的，该列表中的每一个案例都在某种程度上发生。然而，要问的公平问题是"这类问题可能发生的主要原因是什么？”

“权力不平衡”

漏洞赏金的根本问题是它们不仅由公司/供应商创建，而且完全由他们任意定义，安全研究人员任由他们摆布，没有任何追索权（因为你能向谁上诉？向那些创建、定义并决定如何处理报告工作的人？）。我们在权力不平衡方面确实存在问题。

在理想世界中，我们会有公平的条款，双方都可以在安全研究人员甚至开始工作之前就期望在什么情况下得到什么达成一致。漏洞赏金根本不是这样构建的。

此外，有很多虚假和误导性的广告，例如，所有这些展示百万美元漏洞猎人的文章，给人的印象是当你做漏洞赏金时，你也可以变得富有。许多年轻有动力的人，有时生活在与公司完全不同的国家，当他们受到委屈时，几乎没有选择为自己的权利而战。他们可能不知道自己的合法权利，或者没有经验和资本这样做。然而，一些处于这种情况的人试图通过使用社交媒体向公司施压来抗争，我们可以时不时地在Twitter上看到这种情况。

让我们看看研究人员必须处理的漏洞赏金计划问题的一些随机例子（你可以找到多个）：

案例研究

1. Windows 10 RCE案例（2021年12月7日）

   • 研究人员遇到了7个一般潜在问题中的6个
   • 微软最初误判并完全驳回了该问题
   • 上诉后，问题被分类为"严重，RCE”，但只支付了广告赏金的10%（5千美元 vs 5万美元）
   • 5个月后提出的补丁未能正确解决底层参数注入问题

2. DirectX虚拟化功能漏洞

   • 范围不明确导致奖励不足
   • 研究人员发现了允许逃离VM边界的漏洞
   • 尽管DirectX不是Hyper-V本身的一部分，但研究人员证明了其可利用性
   • 经纪人建议下次联系他们而不是漏洞赏金计划

3. Microsoft Exchange ProxyShell攻击

   • 范围不明确和拒绝报告
   • 研究人员发现了属于Microsoft的易受ProxyShell攻击的Exchange服务器
   • 微软声称问题超出范围或只有中等严重性，尽管组合利用可实现RCE

4. 重复报告和沟通缓慢

   • 研究人员提交了多个高影响漏洞
   • 数月后供应商以内部已知为由拒绝所有漏洞
   • 供应商未能提供内部发现的证据

5. 奖励不足

   • 研究人员公开Lexmark RCE零日漏洞，而不是"以花生价"出售
   • 强调Pwn2Own竞赛在某些方面已"损坏"
   • 官方披露过程通常冗长而艰巨

“Linux内核i915线性越界读写访问”

那么，本文标题中i915驱动漏洞的故事是什么？有时，当我真的需要从日常工作中休息一下，并且对LKRG工作感到精疲力尽，但同时我仍然想进行漏洞研究（我很少处于这种状态），我要么阅读（为了乐趣）OpenSSH的源代码（这导致了例如CVE-2019-16905或CVE-2011-5000），要么阅读Linux内核。

2021年11月，在分析i915驱动期间，我发现了一个线性越界读写访问，导致内存损坏和/或内存泄漏错误。该漏洞存在于vm_access函数中，通常用于调试进程。此函数仅需要用于VM_IO | VM_PFNMAP VMA：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

static int
vm_access(struct vm_area_struct *area, unsigned long addr,
void *buf, int len, int write)
{
...
if (write) {
[1] memcpy(vaddr + addr, buf, len);
    __i915_gem_object_flush_map(obj, addr, len);
} else {
[2] memcpy(buf, vaddr + addr, len);
}
...
}

参数len从未验证，并直接用作memcpy()函数的参数。在第[1]行，memcpy()函数将用户控制的数据写入"固定"页面，导致潜在的内存损坏/溢出漏洞。在第[2]行，memcpy()函数从"固定"页面读取内存（数据）到用户可见区域，导致潜在的内存泄漏问题。

该漏洞的完整详细描述以及所有分析（和PoC）可以在这里找到。

我确定了3个可用于触发漏洞的不同接口，并与我的朋友Jared分享了我的发现，我们开始研究PoC。我们很快开发了一个非常可靠的PoC，使内核崩溃。

在这一点上，我通常决定开发完全武器化的漏洞利用，或者尽快联系供应商报告和修复问题。然而，出于好奇，我想知道Intel的GPU（带有i915驱动）在哪些地方启用（默认情况下），我意识到它在多个有趣的地方使用，包括：

• Google Chromebook / Chromium
• 大多数商务笔记本电脑
• 高能效笔记本电脑
• 任何使用带有集成GPU的Intel CPU的设备

但是等等……点"a."（Chromebook）不是有漏洞赏金计划吗？也许这是我自己尝试漏洞赏金的好时机？它到底是如何工作的？每个人都称赞Google和他们的安全性，对吧？

那么，让我们看看这里发生了什么。根据Chrome漏洞奖励计划规则：

“除了程序认可的Chrome错误类别外，我们还对证明Chrome OS硬件、固件和OS组件中漏洞的报告感兴趣。…沙箱逃逸…在Chrome OS上，沙箱逃逸报告的额外组件在范围内。这些包括：…在内核上下文中获得代码执行。…”

好的，看起来这应该在他们漏洞赏金的范围内。让我们尝试这条路径，看看进展如何。我没有太多时间再花在这个漏洞上，但我稍微修改了PoC以泄露某些东西（不仅仅是使内核崩溃）。这相对容易，所以我打开了错误并等待看它会如何发展。

然后在星期六（2022年2月5日），我有一些额外的空闲时间，决定看看武器化PoC有多容易，我意识到一些不太好的事情……当我开发泄露某些有趣内容的PoC时，我是在我的调试机器上使用特殊配置（包括KASAN等）完成的。令我惊讶的是，当我在"全新干净"的VM上重新运行我的PoC时，我不断使内核崩溃，没有泄露任何东西。嗯……这开始困扰我，所以我花了一些时间分析发生了什么。经过繁重的工作和与spender的技术讨论（向grsecurity致敬），我意识到当你启用PFN重映射（用于调试我的某些外围设备）与KASAN时，设置了VM_NO_GUARD标志。当KASEN未启用时，不幸的是，vmap()和vmap_pfn()在映射顶部放置GUARD页面，就像vmalloc()在每个分配顶部添加GUARD页面一样。因此，我的PoC在我的调试内核上工作得很好，但在"全新"VM上不行。嗯……我认为我应该更新我打开的错误，以保持公平和透明，我分享了所有信息（包括在咨询中更新技术细节并添加相关内核代码片段）。

在这一点上，我有点期望Chromebook配置在生产上不启用KASAN（他们为什么要这样做？:))所以即使漏洞本身很好，它也只允许使内核崩溃（除非启用KASEN，否则没有代码执行；-))。然而，无论如何应该修复这个漏洞（即使它是内核DoS），并且由于非标准配置（带有VM_NO_GUARD标志），它是可利用的。Google根据我分享的内容总结了该漏洞：

“感谢详细报告！这个是否也已经报告给上游Linux和/或驱动维护者？

根据我的理解，总结如下：

• i915 GPU缓冲区可以通过vm_remote_access访问（旨在调试不驻留在用户空间进程地址空间中的缓冲区）
• 执行内存访问的函数缺少长度检查，允许用户空间尝试越过缓冲区末端进行OOB读写
• 标准内核配置有保护页面，这会导致内核中的访问违规，而不是实际的OOB访问

假设上述正确，这是一个拒绝服务情况（因为我们可靠地崩溃访问保护页面），因此严重性-低。我们仍然希望修复此问题，但等待上游修复然后通过稳定分支使用修复就足够了。”

此外，他们确认PoC使所有内核崩溃。我并不同意"导致内核中的访问违规，而不是实际的OOB访问"的陈述，因为事实恰恰相反。它确实是实际的OOB访问，因此导致访问违规。然而，我决定不挑剔，忽略了它。我确认了他们的陈述，Google将其严重性分配为"低"，并告知我他们会将所有信息转发给Intel PSIRT……当然。现在"有趣"的部分开始了……

• 我于2022年2月3日向Google报告了该问题
• Google于2022年2月8日向Intel报告了该问题
• Google沉默了58天
• 2022年4月7日，我询问是否有任何更新
• 又沉默了5-6天

2022年4月12日，我正在为最新的vanilla内核进行一些LKRG开发，在git同步期间，我意识到我发现漏洞的i915内核文件已更新。嗯……在近2个月没有从Google获得任何更新的情况下，开始看到该文件上的这种"随机"更新是"可疑的"。让我们看看发生了什么……我发现的完全震惊了我。

我找到了以下提交，于2022年3月11日修复了报告的问题（在我最近向Google询问更新前29天）。在提交消息中，他们使用了错误的电子邮件地址：“Suggested-by: Adam Zabrocki adamza@microsoft.com”。我自2019年以来就没有为Microsoft工作，我从不同的电子邮件地址（gmail.com而不是microsoft.com）报告了此问题。

此外，我找到了以下讨论，开始于2022年3月3日。提交表明漏洞是由Intel内部人员发现的，而不是由我发现的（啊哈……）：

1
2
3
4
5
6
7

Signed-off-by: Mastan Katragadda mastanx.katragadda@intel.com
Suggested-by: Adam Zabrocki adamza@microsoft.com
Reported-by: Jackson Cody cody.jackson@intel.com
Cc: Chris Wilson chris@chris-wilson.co.uk
Cc: Jon Bloomfield jon.bloomfield@intel.com
Cc: Sudeep Dutt sudeep.dutt@intel.com
Cc: stable@vger.kernel.org # v5.8+

来自kernel.org的"Reported-by"标签定义：“Reported-by标签向发现并报告漏洞的人员给予荣誉，并希望激励他们将来再次帮助我们。”

总之，Google沉默了58天，他们没有回复我的消息，与此同时Intel在一个多月前修复了漏洞，暗示他们自己发现了漏洞。然而，作为安慰奖，他们把我列为补丁的作者，使用我旧的Microsoft地址（而如我之前提到的，我自2019年以来就没有为Microsoft工作）。到目前为止，漏洞赏金计划做得很好！

看起来我迄今为止遇到了以下问题：

• “沟通缓慢或不回应”——事实上，我会将其提升为完全没有沟通
• “缺乏透明度”——漏洞如何最终被修复，近2个月没有人提供任何更新
• “没有公开认可”——修复表明漏洞是由Intel内部发现的

我将所有发现写信给Google，之后他们终于回复说他们没有联系Intel，Intel也没有联系他们。Google已承担责任作为处理漏洞报告/修复过程的协调者，但在2个月内没有跟进发生了什么。

除了列出的漏洞赏金计划潜在问题外，像Google这样的"中间人"可能值得拥有自己独特的问题列表。然而，与此同时，所描述的问题可以归入"沟通缓慢或不回应"和"缺乏透明度"的范畴。

回到主要故事，Google将我添加到邮件线程中，然后又沉默了。与此同时，我开始直接与Intel交谈，4月12日他们承诺在周末前回复我，在弄清楚发生了什么之后。我在4月14日提醒他们，他们仍然沉默。然后我在18日再次联系他们，因为当然我在周末没有收到他们的回复（“沟通缓慢或不回应"和"缺乏透明度”）。然后我得到了一个回复，有点……奇怪？

“我感谢您对此的耐心。该问题已收到积极分类并且可重现。我们目前正在与产品团队合作以确定严重性评分并推动缓解措施。(…)”

这个回复没有意义，因为在对话期间，Intel已经为此问题创建了补丁（2022年3月3日上午6:04），并于2022年3月14日合并到官方Linux内核中。简而言之，该漏洞已被修复，推送到Linux git仓库，使其在过去的40多天里基本上公开。尽管如此，没有分配CVE，安全公告也没有发布。然而，Intel声称他们仍在分类该问题……

我也不明白为什么我必须开始解决我没有创建的问题。这个漏洞正式报告给Google，我期望Google的责任是正确处理沟通和修复。我向Google询问了这一点，得到的回复是一个长长的公司声明，简而言之是"这是Intel的问题，不是我们的。我们没问题，严重性很低，所以你有什么问题？"

嗯……我理解并完全同意组件所有者（在这种情况下是Intel）的责任是处理任何修复。尽管，我会质疑这种沟通是否是行业标准，因为在整个过程中（2月至4月）没有与研究人