2010-10-05 安全发布详情：外部 PL 漏洞

以下是 CVE-2010-3433 中报告的权限提升漏洞的详细信息，该漏洞已在 2010-10-05 PostgreSQL 更新发布中修复。虽然此安全问题风险较低，并且不会影响大多数用户，但其细节比较复杂，因此需要详细说明，以便明确界定哪些用户会受到影响。

哪些用户受到此漏洞影响？

使用外部、可信、解释型过程语言（“PLs”）的用户，以及使用更改权限的代码（例如 SECURITY DEFINER 函数、SET ROLE 和 SET SESSION AUTHORIZATION）的用户。

此漏洞利用的风险级别是什么？

低。它需要以下所有条件：

攻击者必须具有到数据库服务器的已验证连接。
攻击者必须能够通过该连接执行任意语句。
攻击者必须熟悉 PostgreSQL。
您的应用程序必须包含外部过程语言中的过程或函数。
这些函数和过程必须由具有比攻击者更高权限的用户使用 SECURITY DEFINER 或 SET ROLE 执行，并且使用与攻击者相同的连接。

以上内容可能看起来有些晦涩。但是，PostgreSQL 项目认真对待我们作为“默认情况下最安全”[1] 的地位，并认为没有安全漏洞太小而无法修复。此外，此漏洞专门针对那些尝试通过使用存储过程和其他机制来保护其数据，因此需要解决的用户。

哪些过程语言受到影响？

PL	受影响？	已打补丁？	评论
PL/pgsql	否	否	不受影响
PL/perl	是	是	2010-10-05 安全更新
PL/tcl	是	是	2010-10-05 安全更新
PL/pythonU	否	否	仅限不可信，不受影响
PL/R	否	否	仅限不可信，不受影响
PL/PHP	是	否	正在开发中 PL/PHP 项目
PL/Java	???	否	不确定是否受影响
PL/Ruby	???	否	不确定是否受影响
PL/sh	否	否	仅限不可信，不受影响

其他 PL，例如 PL/Mono、PL/C++、PL/scheme、PL/XSLT、PL/matlab、PL/LOLCODE 和 PL/Lua 目前功能和采用范围有限，因此假定它们不会构成重大风险。鼓励所有 PL 的作者或贡献者检查其 PL 中是否存在此漏洞，并向其用户提供补丁以及对本页的更新。

如果我不使用存储过程，我会受到影响吗？

不会。您不会受到影响。

事实上，只有当您将存储过程与某种权限更改语句一起使用时才会受到攻击，例如 SECURITY DEFINER、SET ROLE 和 SET SESSION AUTHORIZATION。

此漏洞利用的详情是什么？

作为过程语言使用的几种外部语言支持诸如在运行时重新定义模块、绑定变量和其他对象等功能。攻击者（一个经过验证的 PostgreSQL 用户，具有创建函数的足够权限，默认情况下可用）可以使用此功能重新定义基本的语言组件。如果在同一会话中通过不同的 ROLE 调用相同语言中的函数（尤其是调用 SECURITY DEFINER 函数）完成此操作，则这会导致以该用户的权限而不是攻击者的权限执行任意代码。

此机制可用于绕过例如在连接上使用 SET ROLE 来限制用户权限。更危险的是，它可以用来劫持 SECURITY DEFINER 函数，并执行攻击者想要的任何“副作用”代码。

“不可信”语言不受影响，因为只有数据库超级用户可以使用它们来创建函数，并且不可信版本的语言不会使用与可信版本相同的解释器。但是，如果您同时安装了可信版本和不可信版本的语言，您仍然可能受到攻击。

2010-10-05 安全更新如何修复此漏洞？

它更改了 PL/perl 和 PL/tcl，使其为每个数据库 ROLE 启动一个单独的解释器。

这会破坏任何向后兼容性吗？

对于大多数用户来说不会。但是，那些依赖于使用共享哈希、模块等在数据库 ROLE 或 SECURITY DEFINER 函数之间传递变量或代码的功能的用户可能会发现，他们需要在应用此更新之前修改其应用程序。建议所有此类数据传递都使用由同一单个非登录 ROLE 拥有的 SECURITY DEFINER 函数。

就像经常发生的那样，我们认为是安全漏洞的东西，一些用户可能认为是功能。对于由此带来的不便，我们向这些用户表示歉意。

可信语言和不可信语言有什么区别？

“可信”过程语言是指任何具有创建函数权限的数据库用户都可以使用它们来创建新函数或修改现有函数的语言。“不可信”语言是指只有数据库超级用户才能使用它们来创建新函数的语言，因为它们可能会在“安全”数据库容器之外执行代码。

几种语言（包括 PL/perl、PL/tcl 和 PL/PHP）可以安装为可信、不可信或两者。有人指出，我们使用“可信”和“不可信”这两个词语正好颠倒了，但经过 13 年，这样的用法很难改变。

我无法立即应用更新，或者我的 PL 未打补丁。如何解决此漏洞？

首先，三个基本预防措施可以减少您受到此漏洞和其他权限提升漏洞攻击的风险：

显然，您希望阻止用户在您的数据库上执行任意代码。为了利用此漏洞，用户必须经过验证，并且能够创建新的自定义函数。
如果您使用 SECURITY DEFINER 函数，您希望确保如以前的安全修复中所述设置此类函数的 search_path。
现有的函数和存储过程应该由与您的应用程序或 Web 用户关联的登录角色不同的角色拥有，以便它们无法轻松修改。

立即的解决方法是从普通用户中删除创建新函数的所有权限，无论如何，对于生产数据库来说，这是一个好主意。

 REVOKE USAGE ON LANGUAGE procedural_language FROM PUBLIC;
 example: REVOKE USAGE ON LANGUAGE plruby FROM PUBLIC;

如果特定用户随后需要创建函数的能力，则可以分别授予他们此权限。

是否存在已知的针对此问题的漏洞利用脚本？

没有。

那么谁发现了此漏洞？

PostgreSQL 贡献者和 Perl DBI 创建者 Tim Bunce，他在改进 PL/perl 时发现了此漏洞。

我是外部 PL 的维护者，希望与某人联系以修复我的 PL

请联系 [email protected] 与 PostgreSQL 安全团队讨论此事。

20101005 安全发布

目录