漏洞赏金计划的困境：i915漏洞与ChromeOS、Intel赏金项目背后的故事

引言

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

漏洞赏金计划的历史背景

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

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

历史回顾

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

“不再免费提供漏洞"运动

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

漏洞赏金计划 - 美好的新世界？

漏洞赏金计划不仅使研究人员受益。事实上，如果公司的安全性足够成熟，并且他们的产品开发是安全导向的，它们实际上可以带来很多好处：

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

“漏洞赏金计划已损坏”

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

权力不平衡

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

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

2021年11月，在分析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的漏洞赏金计划，但经历了以下问题：

2022年2月3日：向Google报告问题
2022年2月8日：Google向Intel报告问题
Google沉默了58天
2022年3月11日：我发现Linux内核中已经有一个提交修复了报告的问题
提交信息错误地使用了我的旧Microsoft邮箱地址
提交暗示漏洞是由Intel内部发现的，而不是我

经验教训

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

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

结论

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