漏洞赏金计划的困境——从i915漏洞看ChromeOS与英特尔赏金程序的问题
引言
最初我并未打算撰写关于漏洞赏金计划问题的文章。这本应是一篇标准的技术博客,描述Linux内核i915驱动中一个有趣的漏洞(CVE-2023-28410),该漏洞允许线性越界读写访问。我甚至并不热衷参与漏洞赏金计划,因为我很幸运拥有一份满意、稳定且收入可观的工作。
尽管如此,在业余时间,除了开发和维护Linux内核运行时防护(LKRG)项目外,我仍然喜欢进行漏洞研究和利用开发,不仅为雇主工作,偶尔更新简历中的CVE编号也是好事。在我开始有稳定收入之前,漏洞赏金计划并不存在,大多数高质量的漏洞研究成果通过经纪人支付账单(我们暂且搁置由此产生的道德问题)。然而,如今我们有了漏洞赏金计划…
漏洞赏金计划的历史与现状
在过去的十年(甚至更长)里,漏洞赏金计划获得了应有的关注。有些安全研究人员依靠漏洞赏金作为主要收入来源。这些案例无可辩驳地证明了漏洞赏金计划的成功。但在行业发展到今天这个状态之前,它经历了一段漫长而有趣的历程。
历史背景
- 1993年11月5日:Scott Chasin创建bugtraq邮件列表
- 2002年7月9日:Len Rose创建Full Disclosure邮件列表
- 协调披露(Coordinated Disclosure)政策的发展
- “No More Free Bugs"运动(2009年)
漏洞赏金计划的问题现状
虽然漏洞赏金计划非常成功,研究人员和公司都能从中受益,但近年来越来越多的安全研究人员开始大声抱怨某些特定的赏金计划。这些不利意见在几年前还是边缘化的,但现在变得越来越明显。
研究人员面临的主要风险
- 奖励不足 - 特别是对于高严重性漏洞
- 沟通缓慢或不响应 - 特别是在分类和处理报告时
- 缺乏透明度 - 如何运行赏金计划以及如何确定奖励
- 范围不明确 - 难以知道哪些漏洞在范围内
- 重复报告 - 报告后发现已被他人报告
- 报告被拒绝 - 没有明确解释
- 缺乏公开认可 - 只有金钱奖励没有名誉认可
权力失衡:根本问题
漏洞赏金计划的基本问题是它们不仅由公司/供应商创建,而且完全由他们任意定义,安全研究人员处于他们的支配之下,没有任何追索权。我们确实存在权力失衡的问题。
在理想的世界中,我们会有公平的条款,双方可以在安全研究人员开始工作之前就各种情况下的期望达成一致。漏洞赏金计划根本不是这样构建的。
i915漏洞的真实案例
漏洞技术细节
2021年11月,在分析i915驱动时,我发现了一个线性越界读写访问漏洞,会导致内存损坏和/或内存泄漏。该漏洞存在于vm_access函数中,该函数通常用于调试进程。
|
|
参数len从未经过验证,直接用作memcpy()函数的参数。在行[1]处,memcpy()函数将用户控制的数据写入"固定"页面,导致潜在的内存损坏/溢出漏洞。在行[2]处,memcpy()函数从"固定"页面读取内存(数据)到用户可见区域,导致潜在的内存泄漏问题。
报告过程的时间线
- 2022年2月3日:向Google报告漏洞
- 2022年2月8日:Google向Intel PSIRT报告
- 58天沉默期
- 2022年3月11日:发现Linux内核中已有修复提交
- 2022年10月:Intel最终发布安全公告
遇到的问题
- 沟通缓慢或不响应 - Google长达58天没有更新
- 缺乏透明度 - 漏洞如何被修复的细节不明确
- 缺乏公开认可 - 修复建议漏洞是Intel内部发现的
经验教训与结论
我的漏洞赏金体验比预期糟糕得多。特别是Google的态度是永远保持沉默,直到事情明显出错。然后,他们试图将所有责任推给Intel,并说服我这不是他们的问题,尽管漏洞是向他们报告的,而且他们"很好地"处理了沟通。
作为研究人员,你能做什么?什么也做不了。
Intel搞砸了,但他们尽力修复了他们搞乱的部分(以及当时仍然可以修复的部分)。与Google的态度相反,Intel没有责怪任何人,也没有试图说服我他们正在尽力而为,他们没有敷衍了事。
如果这个漏洞真的具有可利用价值,看起来最好的选择仍然是重新联系老经纪人(如果我们把道德问题放在一边)。他们从来没有失败得这么严重(至少这是我的经验),尽管他们也不完美。
呼吁改变
我希望我们作为安全社区可以开始讨论如何解决漏洞赏金计划中这些未言明的问题。“权力失衡"是研究人员面临的真实问题,应该改变。
我们需要:
- 更公平的条款和条件
- 更好的沟通流程
- 更高的透明度
- 对研究人员工作的适当认可
- 独立的仲裁机制
只有通过解决这些根本问题,漏洞赏金计划才能实现其最初的承诺:让互联网对每个人都更加安全。