漏洞赏金计划的困境：i915漏洞、ChromeOS + Intel赏金项目及其他

引言

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

尽管如此，在业余时间，除了开发和维护Linux内核运行时防护（LKRG）项目外，我仍然喜欢进行漏洞研究和漏洞开发，不仅为我的雇主工作，偶尔也会用新的CVE编号更新我的简历。

漏洞赏金计划的历史背景

在过去的十年（稍长一些），漏洞赏金计划获得了应有的关注。有些安全研究人员依靠漏洞赏金作为他们的主要收入来源。这些案例无可辩驳地证明了漏洞赏金计划的成功。

然而，在这个行业发展到今天这个状态之前，它经历了一条漫长而有趣的道路。

一点历史

• 1993年11月5日，Scott Chasin创建了bugtraq邮件列表
• 2002年7月9日，Len Rose创建了"完全披露"邮件列表
• 协调披露（也称为"负责任披露"）政策逐渐形成

“不再免费提供漏洞”

2009年3月，在CanSecWest会议上，Alex Sotirov、Dino Dai Zovi和Charlie Miller宣布了"不再免费提供漏洞"运动，传播了在大多数情况下他们将不再向供应商免费提供漏洞通知的信息。

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

从公司的角度来看，漏洞赏金计划可以带来很多好处：

• 成本效益高的漏洞管理
• 品牌声誉
• 保护品牌
• 对潜在客户的"广告"

“漏洞赏金计划已损坏”

正如我们所看到的，漏洞赏金非常成功，因为研究人员和公司双方都能从中受益。然而，近年来，越来越多的安全研究人员开始大声抱怨一些特定的赏金计划。

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

1. 奖励不足
2. 沟通缓慢或无响应
3. 缺乏透明度
4. 范围不明确
5. 重复报告
6. 报告被拒绝
7. 无公开认可

“权力失衡”

漏洞赏金的根本问题是，它们不仅由公司/供应商创建，而且完全由他们任意定义，安全研究人员处于他们的支配之下，没有任何追索权。

具体案例研究

1) Windows 10 RCE案例

研究人员发现了Windows 10中的远程代码执行漏洞，但微软最初完全忽视了该问题。上诉后，问题被分类为"严重，RCE"，但只获得了广告赏金的10%（5千美元 vs 5万美元）。

2) DirectX虚拟化功能漏洞

研究人员发现了DirectX虚拟化功能中的漏洞，允许他逃离VM边界。但由于范围问题，奖励不足。

3) Microsoft Exchange ProxyShell攻击

研究人员发现了多个属于微软的Microsoft Exchange服务器实例容易受到ProxyShell攻击，但微软声称所有问题都在范围之外，和/或只有中等严重性。

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

技术细节

在分析i915驱动程序时，我发现了一个线性越界读写访问，导致内存损坏和/或内存泄漏错误。该漏洞存在于vm_access函数中，通常用于调试进程。

 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()函数从"固定"页面读取内存（数据）到用户可见区域，导致潜在的内存泄漏问题。

与Google和Intel的互动

我将此漏洞报告给了Google的Chrome漏洞奖励计划，因为i915驱动程序在Chromebook中默认使用。

• 2022年2月3日：向Google报告问题
• 2022年2月8日：Google向Intel报告问题
• 然后Google沉默了58天
• 2022年3月11日：我发现Linux内核中已经提交了修复此问题的commit

在commit消息中，他们使用了错误的电子邮件地址，并暗示该漏洞是由Intel内部发现的，而不是我。

经验教训

我的漏洞赏金体验比预期的要糟糕得多。特别是Google的态度是永远保持沉默，直到事情明显出错。然后，他们试图将所有责任推给Intel，并说服我这不是他们的问题，即使漏洞是向他们报告的，并且他们负责沟通。

Intel搞砸了，但他们尽力修复了他们搞砸的事情（以及在那个时候仍然可以修复的东西）。与Google的态度相反，Intel没有责怪任何人，也没有试图说服我他们正在尽力而为，他们没有不屑一顾。

结语

我希望我们作为安全社区可以开始讨论如何解决漏洞赏金计划中这些未言明的问题。“权力失衡"是研究人员的真正问题，应该改变。