2025年9月25日: PostgreSQL 18 发布!

2013-04-04 安全发布常见问题解答

本次发布包含以下版本

  • v9.2.4
  • v9.1.9
  • v9.0.13
  • v8.4.17

虽然本常见问题解答总体上涵盖了 2013-04-04 PostgreSQL 安全更新,但其大部分内容侧重于本次发布中修复的主要安全漏洞,即 CVE-2013-1899

此漏洞是否存在已知的“野外”利用情况?

发布时,没有已知的利用情况。

由于此问题,哪些用户特别容易受到攻击?

任何允许无限制访问 PostgreSQL 网络端口的系统,例如在公共云上运行 PostgreSQL 的用户,尤其容易受到攻击。服务器只能在受保护的内部网络上访问,或者具有有效防火墙或其他网络访问限制的用户,受攻击的风险较低。

这是数据库安全的一个良好通用规则:除非绝对必要,否则不要允许从不受信任的网络访问数据库服务器端口。这一点对于 PostgreSQL 和其他数据库系统都同样适用,甚至更适用。

该漏洞的性质是什么?

该漏洞允许用户在 PostgreSQL 以正常的多用户模式运行时,使用用于 PostgreSQL 连接的命令行开关,而该开关本应仅用于单用户恢复模式。这可能被用来损害服务器。

此漏洞可能带来哪些潜在的利用方式?

  1. 持久性拒绝服务:未经身份验证的攻击者可以利用此漏洞,将 PostgreSQL 错误消息附加到服务器上 PostgreSQL 数据目录中的目标文件中。以这种方式损坏的文件可能导致数据库服务器崩溃,并拒绝启动。可以通过编辑文件并删除垃圾文本,或从备份恢复来修复数据库服务器。
  2. 配置设置权限提升:如果攻击者能够合法登录数据库服务器,并且服务器的配置使得用户名和数据库名称相同(例如,用户为 *web*,数据库为 *web*),则可以利用此漏洞暂时以超级用户的权限设置一个配置变量。
  3. 任意代码执行:如果攻击者满足上述第 2 条中的所有条件,并且能够将文件保存到文件系统(即使是到 *tmp* 目录),那么他们就可以利用此漏洞加载并执行任意 C 代码。SELinux 会阻止这种特定类型的利用。

PostgreSQL 的哪些主要版本受到影响?

9.0、9.1 和 9.2 版本。

8.4 版本用户不受影响。8.3 及更早版本用户不受此问题影响,但由于这些版本已停止支持,因此容易受到其他未修补的安全漏洞的影响。

用户如何保护自己?

  • 尽快下载更新版本并更新所有服务器。
  • 确保 PostgreSQL 未对来自不受信任网络的连接开放。
  • 审计您的数据库用户,以确保所有登录都需要正确的凭据,并且存在的登录都是合法的且当前正在使用的。

使用高级安全框架,例如带有 PostgreSQL 的 SEPostgres 扩展的 SELinux,也可以减少或消除 PostgreSQL 安全漏洞带来的暴露和潜在损害。

谁能够获取有关该漏洞的信息?

有关该漏洞的详细信息首先披露给了我们的安全团队。

PostgreSQL 全球开发组 (PGDG) 多年来一直有一项政策,允许构建要分发给公众的 PostgreSQL 二进制软件包(如 RPM 和 Windows 安装程序)的工程师提前访问,以便在官方发布日期发布信息和代码,从而使软件包能够按时就绪。这适用于次要版本和主要版本发布。鉴于 PostgreSQL-as-a-Service (PGaaS) 作为分发机制的普及度越来越高,我们正在修订此政策以适应云提供商的情况。新政策仍在编辑中,应很快发布。

该漏洞是什么时候发现的?

该漏洞于 2013 年 3 月 12 日首次报告给 PostgreSQL 全球开发组 (PGDG) 安全团队。

我们在 Red Hat 安全团队的协助下,于 3 月 27 日申请了 CVE。

谁发现了该漏洞?

NTT 开源软件中心的 Mitsumasa Kondo 和 Kyotaro Horiguchi 在进行安全审计时发现的。NTT 是 PostgreSQL 的长期贡献者。

该漏洞是如何报告的?

Kondo-san 和 Horiguchi-san 发送电子邮件至 security@postgresql.org。

据 TechCrunch 和 Hacker News 报道,包括云平台提供商 Heroku 在内的一些实体获得了提前访问权限。为什么会发生这种情况?

Heroku 在与其他打包人员相同的时间获得了修复了该漏洞的更新源代码。由于 Heroku 尤其容易受到攻击,PostgreSQL 核心团队与他们合作——以保护其基础设施,并利用其部署作为安全补丁的测试平台。这有助于验证安全更新没有破坏任何应用程序功能。Heroku 在与社区开发者密切合作以及在其 PostgreSQL 服务中测试实验性功能方面有着悠久的历史。

谁在正式发布前获得了代码访问权限?

我们在 PGDG 基础设施上托管的私人列表上与两个团队进行沟通。在发布任何软件包之前,两个团队都获得了源代码的访问权限,以便分析安全补丁并创建软件包以分发 PostgreSQL 二进制文件。这些是我们的安全团队和打包人员列表。在这两种情况下,这些小组都获得了早期访问权限,以便参与修补安全漏洞。

拥有大型部署或安全敏感应用程序的最终用户如何获得早期访问安全信息?

目前,PostgreSQL 项目不向未直接参与修补安全漏洞或为其他用户打包 PostgreSQL 的用户提供早期访问安全信息、补丁或代码的权限。未来我们有可能提供此类访问权限,但目前尚不可能。

在本次安全讨论期间将存储库设为私有是否恰当?

鉴于漏洞的严重性,PostgreSQL 核心团队经过审议,认为在软件包可用之前提供修复程序源代码所带来的安全风险,超过了公众立即获得访问的利益。

关于安全发布的信息共享的正常程序是在新版本发布前一周向我们的开发者邮件列表 pgsql-hackers@lists.postgresql.org 发送公告。Tom Lane 这样做了。然后,由于安全漏洞的严重性,我们还向 pgsql-announce@postgresql.org 和我们网站主页上的 RSS 新闻源发送了公告。我们这样做是因为我们希望给 DBA 足够的时间来规划维护窗口进行升级。

公告和发布的时间安排是基于志愿者打包人员和发布经理能够进行发布的可用性。

PostgreSQL 项目是如何组织的?

PostgreSQL 全球开发组 (PGDG) 是一个志愿者运营的全球组织。我们有一个六人核心团队,一些主要贡献者以及几个邮件列表,构成了我们社区的中心部分。 此处为贡献者详情

新成员如何加入安全团队或打包人员团队?

这两个团队的成员资格均由核心团队维护。

PostgreSQL 多久会发现一次新的安全漏洞?

我们每年发现零到七个次要安全问题。自 2006 年以来,这是第一次发生如此大规模的安全问题:“反斜杠转义编码问题”,该问题也影响了 MySQL 和其他一些数据库系统。

该漏洞是如何引入的?

它是为了使与 PostgreSQL 服务器建立新连接更快、相关代码更易于维护而进行的重构工作的副作用而产生的。

谁会发现 PostgreSQL 中的漏洞?

我们很幸运拥有一大批安全工程师,他们定期测试 PostgreSQL 并负责任地报告安全问题,以便它们能够得到修复。这包括:

  • NTT Open Source、EnterpriseDB 和 2ndQuadrant 等贡献公司的高级 QA 人员
  • 日本联邦安全机构的安全研究人员
  • Secunia 等安全公司的安全研究人员
  • Coverity 的 Scan 项目
  • 以及我们大量的参与社区用户,他们报告了 Bug。

此版本还包含哪些其他内容?

此版本还更新了四个其他次要安全问题,这些问题在 安全页面 和版本公告中有详细说明。它还包含许多 PostgreSQL 的 Bug 修复,其中最值得注意的是修复了两个潜在的二进制复制数据损坏问题。