漏洞赏金计划的困境：i915漏洞、ChromeOS与英特尔赏金项目内幕

引言

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

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

在我开始有稳定收入之前，漏洞赏金并不存在，大多数高质量的漏洞研究成果都是通过经纪人支付账单的（让我们暂且搁置由此产生的道德问题）。然而，如今我们有了漏洞赏金计划…

漏洞赏金计划简史

在过去的十年（稍长一些）中，漏洞赏金计划获得了应有的关注。有些安全研究人员依靠漏洞赏金作为他们的主要(!)收入来源。这种情况无可辩驳地证明了漏洞赏金计划的成功。然而，在行业发展到现在的状态之前，它经历了一段漫长而有趣的路线。

一点历史：

1993年11月5日，Scott Chasin创建了bugtraq邮件列表，以回应CERT的问题，安全研究人员可以在其中发布漏洞，无论供应商响应如何，作为漏洞披露的完全披露运动的一部分。
2002年7月9日，Len Rose创建了Full Disclosure - 一个"轻度审核"的安全邮件列表，因为许多人觉得bugtraq邮件列表"变得更糟了"。

然而，并非所有人都同意"完全披露"哲学，两个主要的替代方案可以概括为不披露和协调披露（也称为"负责任披露"）。不披露通常受到黑帽黑客的青睐，后来也被商业漏洞供应商（包括经纪人）所青睐。

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

然而，一些研究人员开始对供应商如何处理报告的漏洞（并将研究人员视为敌人）表示担忧，而其他人则开始期望为他们的报告获得补偿（类似漏洞赏金计划）。

“不再免费提供漏洞”

2009年3月，在CanSecWest会议上，Alex Sotirov、Dino Dai Zovi和Charlie Miller宣布了"不再免费提供漏洞"运动，传播了在大多数情况下他们将不再向供应商提供免费漏洞通知的消息。无论它有多么有效（实际上并不太有效：https://twitter.com/0xcharlie/status/1480593646756024323），它确实成为了行业新闻，并就这个问题开启了更广泛的辩论。值得一提的是，在过去，当安全研究人员因工作获得免费T恤时，他们可以认为自己很幸运。真正的回报来自名声和第三方的职位邀请（如果有的话）。

我提到所有这些"过去的问题"的原因是，它们是我们在某种程度上拥有漏洞赏金计划的基础。而且，我们当然不希望行业回到过去的状态。

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

让我们问ChatGPT以下问题：

“漏洞赏金计划的历史是什么？”

“漏洞赏金计划起源于互联网早期，Netscape和Mozilla等公司为发现和报告其软件中的安全漏洞提供奖励。‘漏洞赏金’的概念在2000年代初由美国国防部通过启动漏洞奖励计划（VRP）正式确定。从那时起，许多科技公司和组织实施了类似的计划，为发现和报告其系统中漏洞的安全研究人员提供奖励。这些计划已成为打击网络犯罪的重要工具，因为它们激励个人在恶意行为者利用漏洞之前找到并报告漏洞。”

相当准确！虽然漏洞市场已经发展，但漏洞商业化（或"漏洞赏金"）仍然是一个重要工具，使开发人员能够在公众意识到之前发现和解决错误，防止广泛滥用和数据泄露事件的发生。

然而，有些人可能会问"为什么公司要费心创建漏洞赏金计划？"。这是一个公平的问题，从公司的角度来看，向"随机"人员支付金钱以在其产品中查找错误有什么意义？漏洞赏金不仅使研究人员受益。事实上，如果公司的安全性足够成熟，并且他们的产品开发是安全导向的（通常情况并非如此），它们实际上可以带来很多好处，包括：

成本效益高的漏洞管理 - 漏洞赏金可能比聘请第三方安全公司进行渗透测试或漏洞评估更具成本效益（特别是对于非常复杂和成熟的产品）。此外，通过漏洞赏金计划，公司可以扩大其测试和漏洞研究覆盖范围，因为他们可以拥有许多具有不同专业水平、经验和技能的安全研究人员测试他们的产品和系统。这可以帮助公司找到可能被内部团队遗漏的漏洞。
品牌声誉 - 通过拥有漏洞赏金计划，公司可以表明他们关心安全并愿意投资于安全。它还可以帮助提高公司在安全行业的声誉。
保护品牌 - 通过开放漏洞赏金计划，公司可以鼓励研究人员直接向他们报告漏洞，而不是公开披露或将其出售给恶意行为者。这有助于减轻各种安全风险。
向潜在客户做广告 - 漏洞赏金表明他们认真对待安全，并积极努力识别和解决漏洞。公司可以与客户、合作伙伴和其他利益相关者建立信任。

然而，应该指出的是，拥有漏洞赏金计划并不能替代安全SDLC、定期安全测试和漏洞管理实践等的需求。它是一个额外的安全层，可以补充现有的安全措施。

“漏洞赏金计划已坏”

正如我们所看到的，漏洞赏金非常成功，因为双方 - 研究人员和公司 - 都从中受益。然而，尽管如此，近年来越来越多的安全研究人员开始大声抱怨一些特定的赏金计划。几年前，鉴于漏洞赏金的成功，这种不利意见是边缘化的。当然，它们一直存在，但肯定不像现在这样明显。每当有新公司加入开放漏洞赏金的革命时，他们都会受到（尤其是媒体的）赞扬，因为他们成熟并理解安全问题的重要性，而不是假装安全问题不影响他们。然而，有没有任何媒体文章真正详细分析过这些计划的运作方式？计划的条件中真的没有为研究人员隐藏陷阱吗？

不幸的是，似乎每个月社交媒体（twitter？）都会讨论一些公司围绕其漏洞赏金计划的，委婉地说，有争议的活动。漏洞赏金的黄金时代结束了吗？也许除了更多研究人员开始依赖漏洞赏金作为他们主要（或重要）收入来源之外，几乎没有什么变化。自然，漏洞赏金的问题会严重影响他们的生活，并导致他们更广泛/大胆地提出他们的担忧。

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

奖励不足 - 一些研究人员可能觉得漏洞赏金计划提供的奖励不足，无论是在货币价值还是他们获得的认可方面。对于发现高严重性漏洞的研究人员来说尤其如此，这些漏洞可能更难或更耗时才能找到。
沟通缓慢或无响应 - 研究人员可能会对漏洞赏金计划协调员的缓慢或无响应沟通感到沮丧，特别是在分类和处理报告的漏洞时。
缺乏透明度 - 研究人员可能觉得漏洞赏金计划的运行方式和奖励确定方式缺乏透明度。他们可能还觉得关于哪些漏洞正在修复以及何时修复的沟通不足。
范围不明确 - 研究人员可能觉得漏洞赏金计划的范围没有明确定义，使他们难以知道哪些漏洞在范围内，哪些不在。
重复报告 - 当研究人员报告一个漏洞，然后发现它已经被其他人报告时，他们可能会感到沮丧。如果他们因工作没有得到奖励，这尤其令人沮丧。
拒绝报告 - 研究人员可能觉得他们的报告在没有明确解释的情况下被拒绝，或者他们的报告不被视为漏洞。
没有公开认可 - 一些研究人员可能希望他们的工作得到公开认可，而不仅仅是金钱奖励。

正如您可以想象的那样，该列表中的每一个案例都在某种程度上发生。然而，要问的公平问题是"这些可能性问题背后的主要原因是什么？"

“权力不平衡”

漏洞赏金的根本问题是它们不仅由公司/供应商创建，而且完全由他们任意定义，安全研究人员任由他们摆布，没有任何追索权（因为你能向谁上诉？向那些创建、定义并决定如何处理报告工作的人？）。我们在权力不平衡方面存在问题。

在理想的世界中，我们会有公平的条款，双方可以在安全研究人员甚至开始工作之前就期望在什么情况下得到什么达成一致。漏洞赏金根本不是这样构建的。

此外，有很多虚假和误导性的广告，例如，所有这些显示百万美元漏洞猎人的文章，给人的印象是当您做漏洞赏金时，您也可以变得富有。许多年轻和有动力的人，有时生活在与公司完全不同的国家，当他们受到委屈时，几乎没有选择为自己的权利而战。他们可能不知道自己的合法权利，或者没有这样做的经验和资本。然而，一些处于这种情况的人试图通过使用社交媒体向公司施压来抗争，我们可以时不时地在twitter上看到这种情况。

让我们看看研究人员必须处理的漏洞赏金计划问题的一些随机示例（您可以找到多个）：

1) “拒绝报告”、“沟通缓慢或无响应”、“范围不明确”、“缺乏透明度”、“没有公开认可”，以及上诉后从研究人员的角度来看"奖励不足"：

“Windows 10 RCE：漏洞利用在链接中”（2021年12月7日）

研究人员的博客文章引用： “微软漏洞赏金计划（MSRC）的回应很差：最初，他们误判并完全驳回了这个问题。在我们上诉后，该问题被分类为’严重，RCE’，但只支付了其分类广告赏金的10%（5千美元 vs 5万美元）。他们在5个月后提出的补丁未能正确解决底层的参数注入问题（目前该问题在Windows 11上仍然存在）”

在那种特定情况下，研究人员"击中"了7个一般潜在漏洞赏金问题中的6个(!)（几乎是头奖！:))。阅读与微软沟通的整个部分非常引人入胜且有教育意义（强烈推荐）。值得指出的是： “微软的某些人一定同意我们的观点，因为该报告为我们赢得了180个研究人员认可计划点数，这个数字我们只能解释为60个基础点数加上’符合条件的攻击场景’的3倍奖励乘数。”

2) “范围不明确"导致从研究人员的角度来看"奖励不足”

一位研究人员在DirectX虚拟化功能中发现了一个错误，允许他逃逸VM边界。然而，DirectX本身不是Hyper-V的一部分，而是一个单独的功能，Hyper-V可以使用它来提供某些功能。默认情况下，DirectX是关闭的，除非某些功能选择打开它。然而，研究人员认为，这个特定功能在WSL2以及一些提供DirectX虚拟化（对于某些场景）的云提供商上是默认开启的。

从范围的角度来看，这是一个有趣的案例，因为最终，研究人员开发了PoC并证明它可以逃逸VM边界。无论问题是否在核心Hyper-V组件中，这样的错误在黑市上都是有价值的，一位经纪人建议下次联系他们而不是漏洞赏金计划。

3) “范围不明确"和"拒绝报告”

一位研究人员发现了一些Microsoft Exchange服务器的实例，其IP/域名属于Microsoft，并且它们容易受到ProxyShell攻击。ProxyShell是一个攻击链，利用Microsoft Exchange中的三个已知漏洞：CVE-2021-34473、CVE-2021-34523和CVE-2021-31207。通过利用这些漏洞，攻击者可以执行远程代码执行。

研究人员向MSRC报告了这些问题，大约1个月后，Microsoft修复了所有问题，并向研究人员发送了负面消息，声称所有问题都是：超出范围，和/或只有中等严重性。研究人员认为，通过组合所有这些问题，最终会得到RCE，而RCE肯定不是中等问题（特别是Microsoft修复了报告的问题）。

4) “重复报告"和"沟通缓慢或无响应”

https://twitter.com/matrosov/status/1615815047653265410

一位研究人员提交了多个高影响漏洞，几个月后，供应商拒绝了所有错误，认为他们已经知道这些错误，因为他们在提交之前内部发现了完全相同的错误。然而，与此同时，供应商没有也不能提供任何证据（没有CVE）证明他们真的是自己（内部）发现的。此外，供应商花了很长时间才回应，这引发了关于内部发现的问题（并破坏了可信度）。

5) “奖励不足”

“研究人员放弃Lexmark RCE零日漏洞，而不是以’花生米’价格出售漏洞” https://portswigger.net/daily-swig/researcher-drops-lexmark-rce-zero-day-rather-than-sell-vuln-for-peanuts

文章引用：根据研究人员的说法，Lexmark在零日漏洞发布前没有收到通知，原因有两个。首先，Geissler希望强调Pwn2Own竞赛在某些方面是"破碎的"，正如当为"具有潜在大影响的东西"（如可以危害100多种打印机型号的漏洞利用链）提供低货币奖励时所显示的那样。此外，他表示官方披露过程通常冗长而艰巨。“根据我的经验，通过在公共领域发布交钥匙解决方案而没有任何事先通知，供应商的修补工作大大加快，“Geissler指出。“Lexmark可能会重新考虑未来与类似竞赛的合作，并选择启动自己的漏洞赏金/奖励计划。”

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

那么，本文标题中i915驱动漏洞的故事是什么？有时，当我真的需要从日常工作中休息一下，并且我对LKRG的工作感到筋疲力尽，但同时我仍然想进行漏洞研究（我很少处于这种状态），我要么阅读（为了乐趣）OpenSSH的源代码（这导致了例如CVE-2019-16905或CVE-2011-5000）或Linux内核： https://sourcegraph.com/search?q=context:global+repo:%5Egithub%5C.com/torvalds/linux%24+type:commit+zabrocki&patternType=standard&sm=1&groupBy=path https://github.com/torvalds/linux/search?q=zabrocki&type=commits

2021年11月，在分析i915驱动程序期间，我发现了一个线性越界（OOB）读写访问，导致内存损坏和/或内存泄漏错误。该漏洞存在于vm_access函数中，通常用于调试进程。此函数仅用于VM_IO | VM_PFNMAP VMA：

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

该错误的完整详细描述以及所有分析（和PoC）可以在这里找到： http://site.pi3.com.pl/adv/CVE-2023-28410_i915.txt

我确定了3个不同的接口可以用来触发该错误，并与我的朋友Jared（https://twitter.com/jsc29a）分享了我的发现，我们开始研究PoC。我们很快开发了一个非常可靠的PoC，使内核崩溃：

1
2
3
4
5
6


[ 2706.589001] BUG: unable to handle page fault for address: ffffb23ac04fa000
[ 2706.589011] #PF: supervisor read access in kernel mode
[ 2706.589016] #PF: error_code(0x0000) - not-present page
...
[ 2706.589140] Call Trace:
[ 2706.589264] ? vm_access+0x75/0xc0 [i915]

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

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

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

那么，让我们看看这里发生了什么： https://bughunters.google.com/about/rules/5745167867576320/chrome-vulnerability-reward-program-rules

“…除了程序认可的Chrome错误类别外，我们还对证明Chrome OS硬件、固件和OS组件中存在漏洞的报告感兴趣。…沙箱逃逸…Chrome OS上沙箱逃逸报告的其他组件在范围内。这些包括：…在内核上下文中获得代码执行。…”

好的，看起来这应该在他们漏洞赏金的范围内。让我们尝试那条路，看看进展如何 :) 我没有太多时间再花在这个错误上，但我稍微修改了PoC以泄露一些东西（不仅仅是使内核崩溃）。这相对容易，所以我打开了错误并等待看它会如何发展：

然后在星期六（2022年2月5日），我有一些额外的空闲时间，决定看看武器化PoC有多容易，我意识到一些不太好的事情…当我开发我的PoC泄露一些有趣的东西时，我是在我的调试机器上做的，该机器具有特殊配置，包括KASAN和所有那些。令我惊讶的是，当我在"全新和干净"的VM上重新运行我的PoC时，我不断地使内核崩溃，没有泄露任何东西。嗯…这开始困扰我，所以我花了一些时间分析发生了什么。经过繁重的工作并与spender（向grsecurity致敬）进行技术讨论后，我意识到，当您启用PFN重新映射（用于调试我的一些外围设备）与KASAN时，设置了VM_NO_GUARD标志。当KASEN未启用时，不幸的是，vmap()和vmap_pfn()在映射顶部放置GUARD页面，就像vmalloc()在每个分配顶部添加GUARD页面一样。因此，我的PoC在我的调试内核上工作得很好，但在"全新"VM上不行。嗯…我认为我应该更新我打开的错误以保持公平和透明，我分享了所有信息（包括在咨询中更新技术细节并添加相关内核代码片段）：

在这一点上，我有点期望Chromebook配置在生产上不启用KASAN（他们为什么会呢？:))）所以即使错误本身很棒，它也只允许使内核崩溃（没有代码执行，除非KASAN启用;-))。然而，无论如何应该修复这个错误（即使它是内核DoS），并且由于非标准配置（带有VM_NO_GUARD标志），它是可 exploited 的。Google根据我分享的内容总结了该错误：

“感谢详细报告！这个是否也已经报告给上游Linux和/或驱动程序维护者？

以下是根据我的理解总结：

i915 GPU缓冲区可以通过vm_remote_access访问（用于调试不驻留在用户空间进程地址空间中的缓冲区）执行内存访问的函数缺少长度检查，允许用户空间尝试越界读写越过缓冲区末端标准内核配置有保护页面，这会导致内核中的访问违规，而不是实际的越界访问

假设上述正确，这是一个拒绝服务情况（因为我们可靠地在访问保护页面时崩溃），因此严重性-低。我们仍然希望修复这个，但等待上游修复然后通过稳定分支消费修复就足够了。”

此外，他们确认PoC使所有内核崩溃。我并不同意”（…）导致内核中的访问违规，而不是实际的越界访问"的陈述，因为事实恰恰相反。它确实是实际的越界访问，并因此导致访问违规。然而，我决定不挑剔，忽略了它。我确认了他们的陈述，Google将其严重性分配为"低”，并告知我将把所有信息转发给Intel PSIRT…当然 :) 现在"有趣"的部分开始了…

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

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

我找到了以下提交，于2022年3月11日（在我最近向Google询问更新前29天）修复了报告的问题： https://github.com/torvalds/linux/commit/661412e301e2ca86799aa4f400d1cf0bd38c57c6

在提交消息中，他们使用了错误的电子邮件地址： “Suggested-by: Adam Zabrocki adamza@microsoft.com” 我自2019年以来就没有为Microsoft工作，我从不同的电子邮件地址（gmail.com而不是microsoft.com）报告了这个问题。

此外，我找到了以下讨论： https://patchwork.kernel.org/project/intel-gfx/patch/20220303060428.1668844-1-mastanx.katragadda@intel.com/ 开始于2022年3月3日。

提交表明该错误是由Intel内部人员发现的，而不是由我（啊哈…）： Signed-off-by: Mastan Katragadda mastanx.katragadda@intel.com Suggested-by: Adam Zabrocki adamza@microsoft.com Reported-by: Jackson Cody cody.jackson@intel.com Cc: Chris Wilson chris@chris-wilson.co.uk Cc: Jon Bloomfield jon.bloomfield@intel.com Cc: Sudeep Dutt sudeep.dutt@intel.com Cc: stable@vger.kernel.org # v5.8+

来自kernel.org的"Reported-by"标签定义：“Reported-by标签给予发现并报告错误的人员信用，并希望激励他们将来再次帮助我们。” 所有字段的解释可以在这里找到： https://www.kernel.org/doc/html/v6.3/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

总之，Google沉默了58天，他们没有回复我的消息，与此同时Intel在一个多月前修复了该错误，暗示他们自己发现了该错误。然而，作为安慰奖，他们把我作为补丁的作者，使用我旧的Microsoft地址（而如我之前提到的，我自2019年以来就没有为Microsoft工作）。到目前为止，漏洞赏金计划做得很好！

看起来我迄今为止遇到了以下问题：

“沟通缓慢或无响应” - 事实上，我会将其提升为根本没有沟通
“缺乏透明度” - 错误如何最终被修复，并且几乎2个月没有人提供任何更新
“没有公开认可” - 修复表明该错误是由Intel内部发现的

我将所有发现写信给Google，之后他们终于回复说他们没有联系Intel，Intel也没有联系他们。Google已承担责任成为处理错误报告/修复过程的协调者，但在2个月内没有跟进发生了什么。

除了列出的漏洞赏金计划潜在问题外，像Google这样的"中间人"可能值得拥有自己独特的问题列表。然而，与此同时，所描述的问题可以归入"沟通缓慢或无响应"和"缺乏透明度"的范畴。

回到主要故事，Google将我添加到邮件线程中，然后又沉默了。与此同时，我开始直接与Intel交谈，4月12日他们承诺在周末前回来找我，在弄清楚发生了什么之后。我在4月14日提醒他们，他们仍然沉默。然后我在18日再次联系他们，因为当然我在周末结束时没有收到他们的回复（“沟通缓慢或无响应"和"缺乏透明度”）。然后我得到了一个回复，有点…奇怪？

“我感谢您对此的耐心。该问题已收到积极的分类并且是可重现的。我们目前正在与产品团队合作以确定严重性评分并推动缓解措施。(…)”

这个回复没有意义，因为在对话期间，Intel已经为此问题创建了一个补丁（于2022年3月3日上午6:04），并于2022年3月14日合并到官方Linux内核中。简而言之，该错误已经修复，推送到Linux git仓库，使其在过去的40多天里基本上公开了。尽管如此，没有分配CVE，安全公告也没有发布。然而，Intel声称他们仍在分类该问题…

我也不明白为什么我必须开始解决我没有创建的问题。这个错误是正式报告给Google的，我期望Google的责任是正确处理沟通和修复。我向Google询问了这一点，得到的回复是一个冗长的公司声明，简而言之是说"这是Intel的问题，不是我们的问题。我们没问题，严重性是低的，所以您有什么问题？"

嗯…我理解并完全同意，组件所有者（在这种情况下是Intel）有责任处理任何修复。不过，我会质疑这种沟通是否是行业标准，因为在整个过程中（2月至4月）没有与研究人员的跟进，也没有与供应商的跟进。

当我要求更新时，直到我自己发现错误已经以 shady 的方式修复了至少一个月，我才收到回复。

简而言之，Google的回复可以概括为"这是Intel的问题，现在他们做得很好，他们并不 shady"：

Google的方法可能等同于"范围不明确"类别的问题，但对于"中间人"来说是独特的。作为处理报告给他们的错误的协调者，这是Google的实际责任。

此外，我得到了一个相当有趣的声明：

“我们都是运行和运营安全计划的人类，试图分类我们自己的发现以及来自外部报告者的发现，并试图运行像样的VDP计划。我在Chrome/Chrome OS工作的所有同事都非常感谢外部研究人员 - 如您自己 - 的贡献，他们正在尽力让错误得到修复，并想做正确的事情。有聪明的人和可靠的过程来掌握所有这些，但最终错误会发生 - 错误可能被错误分类，报告可能合并错误方向，给其他人发现的认可，某人可能不总是及时回应。但100%的时间，如果您联系，我们中的一个人会回应，听取您的意见，并与合作，尽可能使事情正确。

从我在上面的评论和电子邮件线程中可以看到，每次您联系mnissler@时，他都相当快地回应了。他只能做这么多来获取您想要的信息，因为我们在那个过程的外部。他确实去尽可能与Intel协调，并为了消除中间人运行通信的需要，将您添加到电子邮件线程中，以便您可以直接与供应商/Intel协调。”

在这些甜言蜜语背后，真正写的是"嗯，糟糕的事情发生了，处理它，不是我们的问题"。此外，缺乏对这里真正发生的事情的任何解释（严重的"缺乏透明度"）。

事实上，她写的东西中没有什么我会不同意的，除了"总是及时回应"（请查看评论14、15、16和17的日期）。几乎2个月没有回复和跟进，那肯定不是"及时回应"（“沟通缓慢或无响应”）。

最疯狂的是，从Google的角度来看，一切都应该按照它应该做的方式完成，包括沟通。我对此感到惊讶，并且我恭敬地不同意这一点。如果在此期间（2022年2月至4月）有人跟进了供应商并发送了哪怕一封电子邮件询问更新，这个混乱本可以避免。

它是如何结束的？

Intel继续"分类该错误"直到2022年10月(!)。他们不断推迟发布日期，从10月到11月，然后到2023年2月…然后到2023年5月（请记住，该错误于2022年2月报告，于2022年3月作为内部发现悄悄修复，最初由我于2021年11月发现:)）。

公告：INTEL-SA-00886 / CVE-2023-28410：

经验教训

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

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

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

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

顺便说一句。为了公平起见，也有漏洞赏金计划的积极例子，比如这个： https://twitter.com/ergot86/status/1618977435898494976

结束语

是否写这篇文章的决定在我心中酝酿了很长时间，原因有很多。然而，当我得出结论，值得描述与漏洞赏金计划相关的通常未说出口的问题（包括我的特定案例）时，以下人员为其最终形式做出了贡献（随机顺序）：

Jared Candelaria (https://twitter.com/jsc29a)
Ilja van Sprundel (https://twitter.com/ivansprundel)
Axel “0vercl0k” Souchet (https://twitter.com/0vercl0k)
Michał “redford” Kowalczyk (https://twitter.com/dsredford)
Gynvael Coldwind (https://twitter.com/gynvael)
Alex Matrosov (https://twitter.com/matrosov)
Michael Larabel (https://twitter.com/michaellarabel)

我希望我们作为一个安全社区可以开始一些对话，讨论如何解决所描述的漏洞赏金未说出口的问题。“权力不平衡"是研究人员的真实问题，应该改变。

谢谢， Adam