漏洞赏金计划已破败 - “i915"漏洞故事、ChromeOS与Intel赏金计划及其他

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

尽管如此，在我的业余时间，除了开发和维护Linux内核运行时防护（LKRG）项目外，我仍然喜欢进行漏洞研究和漏洞利用开发，不仅为我的雇主工作，偶尔用新的CVE编号更新简历也是好事。在我开始有稳定收入之前，漏洞赏金并不存在，大多数高质量的漏洞研究成果通过经纪人支付账单（让我们暂且搁置由此产生的道德问题）。然而，如今我们有了漏洞赏金计划…

漏洞赏金计划的历史背景

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

协调（负责任）的漏洞披露是一项政策，根据该政策，研究人员同意向协调机构报告漏洞，然后该机构将其报告给供应商，跟踪修复和缓解措施，并与包括公众在内的利益相关者协调信息披露。

“不再免费提供漏洞”

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

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

从公司的角度来看，漏洞赏金计划有什么意义？漏洞赏金不仅使研究人员受益。事实上，如果公司的安全性足够成熟，并且他们的产品开发是安全导向的（通常情况并非如此），它们实际上可以带来很多好处，包括：

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

“漏洞赏金计划已破败”

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

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

奖励不足
沟通缓慢或无响应
缺乏透明度
范围不明确
重复报告
报告被拒绝
无公开认可

“权力不平衡”

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

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

那么，本文标题中i915驱动漏洞的故事是什么？有时，当我真的需要从日常工作中休息一下，对LKRG工作感到筋疲力尽，但同时我仍然想进行漏洞研究（我很少处于这种状态），我要么阅读OpenSSH的源代码（这导致了例如CVE-2019-16905或CVE-2011-5000），要么阅读Linux内核。

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

我确定了3个不同的接口可用于触发该漏洞，并与我的朋友Jared分享了发现，我们开始研究PoC。我们很快开发了一个非常可靠的PoC，使内核崩溃。

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

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

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

与Google和Intel的经历

我于2022年2月3日向Google报告了该问题 Google于2022年2月8日向Intel报告了该问题 Google沉默了58天在2022年4月7日，我询问是否有任何更新又沉默了5-6天

在2022年4月12日，当我为最新的vanilla内核进行一些LKRG开发时，在git同步期间，我意识到我发现漏洞的i915内核文件已更新。嗯…在没有从Google获得任何更新近2个月的情况下开始看到该文件上的这种"随机"更新是"可疑的"。让我看看发生了什么…我发现的完全震惊了我。

我发现了以下提交，于2022年3月11日修复了报告的问题（在我最近向Google询问更新前29天）。在提交消息中，他们使用了错误的电子邮件地址：“Suggested-by: Adam Zabrocki adamza@microsoft.com"我自2019年以来就没有为Microsoft工作，我从不同的电子邮件地址报告了此问题（gmail.com不是microsoft.com）。

此外，我发现了以下讨论，于2022年3月3日开始。提交表明该漏洞是由Intel内部人员发现的，而不是由我发现的。

经验教训

我对漏洞赏金的体验比预期的要差得多。特别是Google的态度是永远保持沉默，直到事情变得严重/明显错误。然后，他们试图将一切责任推给Intel，并说服我这不是他们的问题，即使漏洞是向他们报告的，并且他们(!)的沟通处理得很好。作为研究人员，你能做什么？什么也做不了。

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

值得一提的是，Intel正式为此案的处理方式道歉：”(…)我们想为本案的处理方式道歉。我们理解与我们的来回沟通令人沮丧且是一个漫长的过程。(…)“然而，Google方面没有发生类似的事情。

如果这个漏洞从可利用性的角度来看真的很有价值，看起来最好的选择仍然是重新使用旧的经纪人联系人（如果我们把道德问题放在一边）。他们从未失败得如此严重（至少这是我的经验），尽管他们也不理想。

结束语

是否撰写本文的决定在我心中酝酿了很长时间，原因有很多。然而，当我得出结论，值得描述与漏洞赏金计划相关的一般未言明的问题（包括我的具体案例）时，我希望我们作为一个安全社区可以开始就如何解决所描述的漏洞赏金未言明的问题进行一些对话。“权力不平衡"是研究人员的真实问题，应该改变。

漏洞赏金计划的困境与i915漏洞案例分析

本文深入探讨了漏洞赏金计划存在的系统性问题，通过作者亲身经历的i915 Linux内核驱动漏洞案例，揭示了Google和Intel在处理安全漏洞报告过程中的沟通不畅、缺乏透明度等问题。