漏洞赏金计划的困境：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宣布了“不再免费提供漏洞”运动，传播了在大多数情况下他们将不再向供应商免费提供漏洞通知的消息。无论其效果如何（并不真的有效：https://twitter.com/0xcharlie/status/1480593646756024323），它无疑成为了行业新闻，并开启了关于该问题的更广泛辩论。值得一提的是，在过去，当安全研究人员因工作获得免费T恤时，他们可以认为自己很幸运。真正的回报来自名声和第三方的职位offer（如果有的话）。

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

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

让我们问ChatGPT以下问题：

“漏洞赏金计划的历史是什么？” “漏洞赏金计划起源于互联网早期，Netscape和Mozilla等公司为发现和报告其软件中的安全漏洞提供奖励。‘漏洞赏金’的概念在2000年代初由美国国防部通过启动漏洞奖励计划（VRP）正式化。此后，许多技术公司和组织实施了类似计划，为发现和报告其系统中漏洞的安全研究人员提供奖励。这些计划已成为打击网络犯罪的重要工具，因为它们激励个人在恶意行为者利用漏洞之前发现并报告漏洞。”

相当准确！虽然漏洞市场已经发展，漏洞商业化（或“漏洞赏金”）仍然是一个重要工具，允许开发人员在公众意识到之前发现和解决漏洞，防止广泛滥用和数据泄露事件。

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

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

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

“漏洞赏金计划已 broken”

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

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

漏洞赏金（以及任何类型的漏洞报告计划）始终涉及研究人员的风险。一些主要原因（再次感谢ChatGPT！:)）包括：

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

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

“权力失衡”

漏洞赏金的根本问题是它们不仅由公司/供应商创建，而且完全由他们任意定义，安全研究人员处于他们的 mercy，没有任何追索权（因为你能向谁申诉？向那些创建、定义并决定如何处理报告工作的人？）。我们确实存在权力失衡问题。在理想世界中，我们会有公平的条款，双方都可以同意，在安全研究人员甚至开始工作之前，在什么情况下期望什么。漏洞赏金根本不是这样结构的。此外，有很多虚假和误导性广告，例如，所有这些文章展示百万美元的漏洞猎人，给人的印象是当你做漏洞赏金时，你也能变得富有。许多年轻有动力的人，有时生活在与公司完全不同的国家，当他们的权利受到侵犯时，几乎没有选择争取权利。他们可能不知道自己的法律权利，或者没有经验和资本这样做。然而，一些处于这种情况的人试图通过使用社交媒体向公司施加压力来争取，我们可以时不时地看到，例如在twitter上。

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

1. “拒绝报告”、“缓慢或无响应的沟通”、“范围不明确”、“缺乏透明度”、“无公开认可”，以及从研究人员角度上诉后的“奖励不足”： “Windows 10 RCE：漏洞在链接中”（2021年12月7日）

研究人员博客文章引用： “Microsoft漏洞赏金计划（MSRC）的回应很差：最初，他们误判并完全驳回了该问题。在我们上诉后，该问题被分类为‘严重，RCE’，但只获得了其分类广告赏金的10%（5k美元 vs 50k美元）。他们5个月后提出的补丁未能正确解决底层参数注入（目前仍在Windows 11上存在）” 在该特定案例中，研究人员“击中”了7个一般潜在漏洞赏金问题中的6个（几乎是头奖！:))。阅读与Microsoft沟通的整个部分非常有趣和教育性（强烈推荐）。值得指出的是： “Microsoft的某些人一定同意我们，因为该报告为我们赢得了180点研究人员认可计划点数，这个数字我们只能解释为60基础点加上‘合格攻击场景’的3倍奖金乘数。”

2. “范围不明确”导致从研究人员角度“奖励不足”

一名研究人员在DirectX虚拟化功能中发现了一个漏洞，允许他逃离VM边界。然而，DirectX不是Hyper-V本身的一部分，而是一个单独的功能，Hyper-V可以使用它来提供某些功能。DirectX默认关闭，除非某些功能选择打开它。然而，研究人员认为，此特定功能在WSL2以及一些提供DirectX虚拟化的云提供商上默认开启（对于某些场景）。 从范围角度来看，这是一个有趣的案例，因为最终，研究人员开发了PoC并证明它可以逃离VM边界。无论问题是否在核心Hyper-V组件中，此类漏洞在黑市上很有价值，一名经纪人建议下次联系他们而不是漏洞赏金计划：

3. “范围不明确”和“拒绝报告”

一名研究人员发现了一些Microsoft Exchange服务器实例，其IP/域名属于Microsoft，并且它们容易受到ProxyShell攻击。ProxyShell是一种攻击链，利用Microsoft Exchange中的三个已知漏洞：CVE-2021-34473、CVE-2021-34523和CVE-2021-31207。通过利用这些漏洞，攻击者可以执行远程代码执行。 研究人员向MSRC报告了这些问题，大约1个月后Microsoft修复了所有问题并向研究人员发送了负面消息，声称所有问题都是：超出范围，和/或只有中等严重性。研究人员认为，通过组合所有这些问题，最终会得到RCE，而RCE肯定不是中等问题（特别是Microsoft修复了报告的问题）。

4. “重复报告”和“缓慢或无响应的沟通”

https://twitter.com/matrosov/status/1615815047653265410

一名研究人员提交了多个高影响漏洞，几个月后供应商拒绝了所有漏洞，声称他们已知晓这些漏洞，因为他们在提交之前内部发现了完全相同的漏洞。然而，与此同时，供应商没有也不能提供任何证据（无CVE）证明他们确实自己（内部）找到了它们。此外，供应商花了很长时间回应，这引发了关于内部发现的问题（并破坏了可信度）。

5. “奖励不足”

“研究人员放弃Lexmark RCE零日而不是‘以花生米价格’出售漏洞”https://portswigger.net/daily-swig/researcher-drops-lexmark-rce-zero-day-rather-than-sell-vuln-for-peanuts 文章引用： 根据研究人员的说法，Lexmark在零日发布之前没有收到通知，原因有两个。首先，Geissler希望强调Pwn2Own比赛在某些方面是“broken的”，当为“具有潜在大影响的东西”（如可以破坏100多种打印机型号的漏洞链）提供低货币奖励时显示。此外，他表示官方披露过程通常漫长而艰巨。“根据我的经验，通过在公共领域发布交钥匙解决方案而没有任何提前通知，供应商的修补工作大大加速，”Geissler指出。“Lexmark可能会重新考虑未来与类似比赛的合作，并选择启动自己的漏洞赏金/奖励计划。”

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

那么，本文标题中的i915驱动漏洞的故事是什么？有时，当我真的需要从日常工作中休息一下，并且对LKRG工作感到精疲力尽，但同时我仍然想进行漏洞研究（我很少处于这种状态），我要么阅读（为了乐趣）OpenSSH的源代码（这导致了例如CVE-2019-16905或CVE-2011-5000）或Linux内核：https://sourcegraph.com/search?q=context:global+repo:%5Egithub%5C.com/torvalds/linux%24+type:commit+zabrocki&patternType=standard&sm=1&groupBy=pathhttps://github.com/torvalds/linux/search?q=zabrocki&type=commits

2021年11月，在分析i915驱动期间，我发现了一个线性越界（OOB）读写访问，导致内存损坏和/或内存泄漏漏洞。该漏洞存在于‘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）可以在这里找到：http://site.pi3.com.pl/adv/CVE-2023-28410_i915.txt

我确定了3个不同的接口可用于触发该漏洞，并与我的朋友Jared（https://twitter.com/jsc29a）分享了我的发现，我们开始研究PoC。我们 quickly 开发了一个非常可靠的PoC，使内核崩溃：

1

[ 2706.589001] BUG: unable to handle page fault for address: ffffb23ac04fa000[ 2706.589011] #PF: supervisor read access in kernel mode[ 2706.589016] #PF: error_code(0x0000) - not-present page…[ 2706.589140] Call Trace:[ 2706.589264] ? vm_access+0x75/0xc0 [i915]

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

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

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

那么，让我们看看这里发生了什么：https://bughunters.google.com/about/rules/5745167867576320/chrome-vulnerability-reward-program-rules

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

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