漏洞赏金计划的问题：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”

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

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

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

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

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

“权力失衡”

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

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

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

新博客文章：通过ms-officecmd URI处理程序中的参数注入实现Windows 10 RCE。虽然我们的RCE向量（MS Teams）已修复，但参数注入仍然存在。https://t.co/dDodI8QREi— Positive Security (@positive_sec) 2021年12月7日

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

只要它是MSRC认可的范围外的虚拟机逃逸漏洞，即使此组件是wsl2上的默认配置并具有从虚拟机逃逸的能力，它也不被视为虚拟机逃逸漏洞。https://t.co/C4Ksn3BCqU pic.twitter.com/yne3LB724k— rthhh (@rthhh17) 2021年12月2日

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

很遗憾，如果有帮助，下次联系我，如果你有兴趣将其出售给第三方并获得报酬— Maor Shwartz (@malltos92) 2021年11月9日

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

我刚刚发布了如何找到Microsoft服务器RCE问题他们修复了但没有支付任何赏金https://t.co/aR2kESaaFy @msftsecresponse @microsoft #bugbountytips #BugBounty— Dateking (@tx20011613) 2023年1月12日

一名研究人员发现了一些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打印机漏洞+ writeup + 工具，而不是以 peanuts 出售。撰写时的0day：https://t.co/YptEXw3CjJ — 享受！— blasty (@bl4sty) 2023年1月10日

“研究人员放弃Lexmark RCE零日而不是以‘peanuts’出售漏洞”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。我们很快开发了一个非常可靠的PoC，使内核崩溃：

1
2
3
4
5
6


[ 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上沙箱逃逸报告的其他组件在范围内。这些包括：……在内核上下文中获得代码执行。……”

然后在星期六（2022年2月5日），我有一些额外的空闲时间，决定看看武器化PoC有多容易，我意识到一些不太好的事情。当我开发我的PoC泄漏一些有趣的东西时，我