漏洞赏金计划的困境：从“i915”漏洞看ChromeOS与英特尔赏金程序的问题

引言

我原本没打算撰写关于漏洞赏金计划问题的文章。这本该是一篇标准的技术博客，描述Linux内核i915驱动中一个有趣的漏洞（CVE-2023-28410），该漏洞允许线性越界读写访问。我甚至并不热衷漏洞赏金计划，因为我有满意、稳定且收入丰厚的工作。尽管如此，在业余时间，除了开发和维护Linux内核运行时防护（LKRG）项目外，我仍然喜欢进行漏洞研究和漏洞利用开发。

漏洞赏金计划的历史与现状

过去十多年间，漏洞赏金计划获得了应有的关注。有些安全研究人员依靠漏洞赏金作为主要收入来源。这些案例无可辩驳地证明了漏洞赏金计划的成功。然而，在行业发展到当前状态之前，它经历了一段漫长而有趣的路线。

“不再免费提交漏洞”

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

漏洞赏金计划的问题

尽管漏洞赏金计划非常成功，双方（研究人员和公司）都从中受益，但近年来，越来越多的安全研究人员开始大声抱怨某些特定的赏金计划。根本问题在于，漏洞赏金计划不仅由公司/供应商创建，而且完全由他们任意定义，安全研究人员处于他们的支配之下，没有任何追索权。

权力失衡

漏洞赏金计划的基本问题是权力失衡。在理想世界中，双方应在安全研究人员开始工作之前就预期条件达成公平条款。漏洞赏金计划根本不是这样构建的。

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

提交给谷歌ChromeOS漏洞赏金计划

我意识到i915驱动在谷歌Chromebook等设备中默认启用，因此决定通过谷歌的漏洞赏金计划提交该漏洞。然而，整个过程充满了问题：

缓慢或不响应的沟通：谷歌在58天内保持沉默
缺乏透明度：漏洞被悄无声息地修复，没有更新
公开认可缺失：修复建议漏洞是由英特尔内部发现的

经验教训

我与漏洞赏金计划的体验比预期的要糟糕得多。特别是谷歌的态度是永远保持沉默，直到事情明显出错。然后，他们试图将一切责任推给英特尔，并说服我这不是他们的问题。作为研究人员，你能做什么？什么也做不了。

结论

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