我是 The Browser Company 的首席技术官兼联合创始人Hursh。我们想让所有 Arc 用户知道，在 2024 年 8 月 25 日之前，Arc 中存在一个安全漏洞。我们在 8 月 25 日意识到了这个漏洞，并在 8 月 26 日修复了它。此问题允许在用户的计算机上远程执行代码。我们立即修补了此漏洞，已经推出了修复程序，并确认除了发现此漏洞的安全研究人员之外，没有人利用它。这意味着没有成员受到此漏洞的影响，您无需采取任何措施即可受到保护。

尽管影响不大，但这是 Arc 成立以来第一次严重的安全事件。我们正利用这个机会升级一切，从内部安全审查到漏洞赏金计划，再到我们与 Arc 成员就此类事件的沟通。

感谢 xyz3va 的私人报告和随后的公开撰写https://kibty.town/blog/arc/。内部调查正在进行中，但与此同时，希望分享该漏洞的技术细节。

发生了什么？

Arc 有一项名为 Boosts 的功能，可让您使用自定义 CSS 和 Javascript 自定义任何网站。由于在网站上运行任意 Javascript 存在潜在的安全问题，我们选择不让成员共享带有自定义 Javascript 的 Boosts，但我们仍将它们同步到我们的服务器，以便您自己的 Boosts 可在各种设备上使用。

我们使用 Firebase 作为某些 Arc 功能的后端（下文将详细介绍），并使用它来保存 Boost，以便在设备之间共享和同步。不幸的是，我们的 Firebase ACL（访问控制列表，Firebase 保护端点的方式）配置错误，这允许用户在创建 Boost 后通过 Firebase 请求更改其创建者 ID。这允许将任何 Boost 分配给任何用户（前提是您拥有他们的用户 ID），从而为他们激活它，导致在激活 Boost 的网站上运行自定义 CSS 或 JS。

谁受到了影响？

没有 Arc 成员受到此漏洞的影响。我们分析了 Firebase 访问日志，确认除了安全研究人员更改的创建者 ID 之外，没有其他创建者 ID 被更改。

缓解措施

xyz3va 的文章更详细地介绍了缓解此漏洞的步骤。在披露后，我们与他们合作修补了我们的 ACL 以修复此漏洞，并在第二天与他们确认了修复。考虑到漏洞的规模，我们还提交了 CVE，虽然我们尚未建立正式的漏洞赏金计划，但我们努力为该问题提供赏金。

后续处置

这是我们在 Arc 中发现的第一个这种规模的漏洞，我们确实希望借此机会改进我们应对和披露安全漏洞的方式。

针对这一具体问题，我们正在做出一些改变以避免这种情况的发生，并改善我们围绕安全漏洞的沟通：

• 我们已修复在您打开 Boost 编辑器时在导航中泄露您当前网站的问题。我们不会将这些请求记录到任何地方，如果您没有打开 Boosts 编辑器，则不会发出这些请求。无论如何，这违反了我们的隐私政策，并且从一开始就不应该出现在产品中。
• 我们默认禁用同步 Boost 上的 Javascript。任何在其他设备上创建的带有自定义 Javascript 的 Boost 都需要明确启用。
• 我们正在添加 MDM 配置以禁用整个组织的 Boosts。我们将不再使用 Firebase 来推出新功能和新产品，以减轻未来与 ACL 相关的问题。
• 除了每六个月进行一次外部安全审核外，我们还在对现有的 Firebase ACL 进行紧急且更深入的外部审核，以确保没有其他漏洞。我们仍计划在未来的所有功能中不再使用 Firebase。
• 我们正在制定一份安全公告，明确通报漏洞、缓解措施以及受影响人员。Tailscale 出色的安全报告让我们深受启发，我们希望自己也能达到同样的标准。
• 我们正在为赏金制定更清晰的指导方针，明确规定哪些严重程度需要特定的奖励金额。
• 我们正在将安全缓解措施添加到我们的发行说明中。由于这是服务器端修复，因此我们没有想到将其包含在客户端发行说明中，但由于这是成员获取有关 Arc 更新信息的主要场所，因此应该将其包含在那里。
• 我们还加强了我们的安全团队，并聘请了一位新的高级安全工程师。

https://arc.net/blog/CVE-2024-45489-incident-response