Databricks披露PostGIS扩展漏洞修复协作细节

最好的安全漏洞往往伴随着一个好故事

我们一些最好的安全投资并不是工具或扫描器，而是人际关系。Databricks 运行着一个漏洞赏金计划，因为发现平台薄弱环节的最快方式是让有才华、好奇的人去寻找它们，并确保当他们发现问题时，善意的报告能得到善意的回应。大多数报告都是安静的交流：有人发现漏洞，我们修复，然后大家继续前行。

偶尔，其中之一会变成一个真正的好故事。这就是其中之一。

几周前，一位外部研究人员 Mehmet Ince 向我们展示了一个内存安全漏洞，该漏洞存在于托管 Postgres 平台（包括 Lakebase Postgres 和 Neon）上随附的 Postgres 扩展中。值得写下来的不仅仅是这个漏洞，还有它周围发生的事情：我们的检测如何捕捉到他的测试，我们能多快保护客户，以及真正的修复最终如何回到了它应该归属的地方——在开源中，让所有运行相同扩展的人受益，而不仅仅是我们。

如果你运行安全团队、运营托管开源基础设施，或者你只是好奇一个健康的研究者与供应商之间的互动实际上从双方来看是什么样子，那么这篇文章就是为你准备的。Mehmet 已经在他的博客上写了深入的技术利用故事在这里，我们想谈谈合作。

Mehmet 发现了什么

Postgres 扩展生态系统是其受欢迎的主要驱动力，尽管不同供应商的支持程度不同，但客户期望托管服务商支持最广泛使用的核心和第三方选项。其中一个是 PostGIS，地理空间工具包。在 PostGIS 内部有一个更小、不起眼的扩展，叫做address_standardizer，它可以将像123 Main St这样的非结构化地址转换为规范化形式。

Mehmet 发现address_standardizer有一个经典的内存安全缺陷：调用者完全控制的一个值（调用者可以提供的语法“规则”的一部分）被用来索引一个固定大小的内部数组，没有边界检查。如果给它一个超出范围的值，就会导致越界内存访问。

对于托管Postgres 服务来说，关键是谁能触达它。address_standardizer位于普通租户可以安装和使用的扩展集中。所以这不是一个需要特殊权限才能触发的漏洞。普通客户角色可以调用该函数并到达易受攻击的代码路径。这正是将一个小而容易被忽视的漏洞变成平台团队需要认真对待的东西。

我们故意在这里轻描淡写利用细节。Mehmet 的深入探讨妥善地讲解了基本原理，比总结做得更好。

研究者的视角

作者：Mehmet D. Ince

这个故事并不是作为漏洞研究开始的。今年春天，在一次内部会议中，我的团队问我们是否可以将几个 PostgreSQL 实例迁移到托管服务商。作为 PRODAFT（一家欧洲威胁情报公司，约有 50 名工程师）的 CTO，我的职责之一是确保我们为客户提供尽可能安全的服务。

我们自己运行 PostgreSQL 已经超过十年了，但我从未从安全角度认真审查过托管 Postgres 服务商如何提供这些服务。我从 2000 年代初就开始做漏洞研究，所以我总是给自己留一个小窗口来做一些安全研究，更好地理解仅仅在我们的技术栈中添加另一个技术所带来的风险。毫不奇怪，我的“快速审查”往往以某人的收件箱中出现严重漏洞报告而告终。有些习惯难以改掉。

在研究的头几天，我意识到几乎每个服务商都提供大致相同的 Postgres 扩展。一个广泛部署的扩展中的内存损坏漏洞实际上就是 PostgreSQL 本身的内存损坏漏洞。所以我选择了一个名为address_standardizer的扩展作为目标，这是一个几乎无处不在的小型 PostGIS 扩展。

伦敦这里一个周一的晚上大约 7 点，Aaron 出乎意料地给我发来邮件，问我引发 Neon 生产环境警报的活动是否属于我。我当时正致力于将我开发的漏洞利用移植到 Neon PostgreSQL 实例上，看看一个小而无辜的扩展中的简单漏洞是否真的能暴露特权提升路径。我当时有可行的概念验证代码，但我只给他发了一张截图。仅凭那张截图，他就足以开始采取行动了！

我负责任地向供应商披露漏洞已经超过二十年了，即使过了这么多年，要解释这些发现的影响和风险仍然很困难，除非花大量时间找到合适的联系人。我必须说，给 Aaron 和 Databricks 的安全团队点赞，他们主动联系像这样的研究人员，并采取如此迅速的行动！

查看 Mehmet 的帖子了解更多信息。

Databricks 和 Neon 如何回应

从我们的角度来看，这是一个协调披露按预期运作的案例研究。

Mehmet 分享了他的证据，当天结束前，报告已传给相关人员，我们的安全工程师针对 Neon 提供的精确 PostGIS 版本进行了验证。我们确认易受攻击的代码路径可被普通租户角色触达，并据此处理。

早些时候，我们做了一个深思熟虑的决定，我们认为值得明确说明，因为这是每个平台团队最终都会面临的问题：你提供的开源组件中的漏洞仍然是你自己的问题。根本原因在上游的 PostGIS 中，但暴露是我们自己的。我们默认将该扩展放在租户面前，因此影响由我们自己承担。我们没有将其视为“第三方”而置之不理。相反，我们接受了报告，推动了响应，并奖励了提出该问题的研究人员。

在客户面临风险时，我们也不愿受制于上游发布的时间表。我们的扩展构建系统经过特意设计，使我们能够在上游Postgres扩展之上应用任意补丁集，然后进行编译和打包，无论是回溯修复还是在我们自己的构建中禁用有风险的代码路径。由于该补丁集存在于下游而非上游源代码中，我们可以独立于上游发布的时间表采取行动。因此，我们能够迅速采取行动保护客户，并并行工作以妥善修复整个生态系统。

构建持久的修复方案经历了多次迭代。第一次尝试并未覆盖所有情况，我们宁愿多花一周时间把它做好，也不愿发布一个不全面的方案。加固后的修复方案已部署以保护Neon和Lakebase的租户，他们无需自行采取任何行动。

将修复方案回馈给开源社区

接下来是事情变得有趣且有点幸运的地方。

规范的修复方案应归属于PostGIS。这是他们的代码、他们的发布、他们的决定。Databricks感谢PostGIS维护者，他们以志愿者的身份维护着地理空间世界的基础部分。Mehmet显然也有同样的感受，并且付诸行动：他将奖金捐赠给了PostGIS项目，并自掏腰包进行了匹配，将奖励直接投入到整个托管Postgres行业所依赖的志愿者工作中。我们的计划很直接：首先保护我们的客户，然后与Mehmet合作，从根源上修复上游问题，以便每个人使用address_standardizer的都能受益，而不仅仅是Neon。

然后一个巧合使事情变得复杂。大约在同一时间，底层漏洞在上游得到了修补，作为一个小的内存泄漏修复，没有CVE，也没有大张旗鼓。

事实证明，上游的修复并没有覆盖所有情况。Mehmet验证了具体不足之处，并将剩余的修复提交回上游，为整个社区弥补了漏洞。该漏洞链没有分配CVE，这本身就是一个教训，说明一个有意义的内存安全修复很容易作为“次要”清理被塞进发布说明中。

我们关心的要点是：研究人员能够对根本原因采取正确的行动，上游得到了完整的修复，而这一切进行期间，我们的客户已经受到保护。

如果您运行托管开源软件，这意味着什么

如果您运营基于开源组件构建的托管服务（托管数据库或其他任何东西），这个事件中令人不安的真相是，您的攻击面包括您未编写的代码，以及其作者可能从未设想过的威胁模型。 一个规模小、受欢迎、低调的扩展正是那种容易发布且容易被遗忘的东西。

对我们有效的一些方法，可能对您也有用：

• 不仅拥有您的代码，还要承担您的风险敞口。 如果您将一个组件置于不可信输入之前，那么它的缺陷就是您的缺陷，无论谁“拥有”修复方案。
• 保留下游修补的杠杆。 能够在自己的构建中修补或限制某个组件，而无需等待上游发布，这是将“我们知道问题”转变为“客户受到保护”的关键。
• 让负责任的信息披露值得重复。 Mehmet提前给了我们一个没有代码的提示。只有研究人员相信善意的报告会得到善意的回应，这种情况才会持续发生。

如果您是安全研究人员，我们真诚地希望收到您的来信。特别是当您能像Mehmet那样，在平台上展示出真实、可衡量的影响时。请通过hackerone.com/databricks报告。

感谢

感谢Mehmet Ince提供了一份详实、善意的报告，并在上游对根本原因采取了正确的行动。感谢PostGIS维护者，他们的开源工作是依赖它的地理空间世界中重要的一部分。还要感谢Neon和Lakebase的工程师们，他们迅速沉着地将报告转化为已部署的修复方案。

感谢每一位与我们合作使平台更安全的研究人员：我们看到了你们，并且心存感激。我们HackerOne上见。