Mehmet Ince：第2/6部分 | 突破Postgres超级用户防护栏：攻击安全加固扩展 | 托管PostgreSQL行业的系统性风险
内容提要
作者研究托管PostgreSQL服务的安全加固扩展，发现各厂商普遍存在权限提升漏洞：扩展临时借用超级用户身份执行用户查询，但未校验函数OID，攻击者可通过FDW验证器或search_path劫持执行恶意代码。作者共报告76个漏洞，并发现LANGUAGE internal可绕过文件读写限制，最终实现远程代码执行。
延伸解读
托管PostgreSQL安全加固扩展的普遍风险
文章指出，多家托管PostgreSQL服务商（如Azure、Aiven、Supabase等）都使用安全加固扩展来临时借用超级用户权限执行用户查询。但作者在测试中发现，这些扩展普遍存在权限提升漏洞，共报告76个漏洞。根本原因在于扩展在提升权限后，未对函数OID进行校验，导致攻击者可通过FDW验证器或search_path劫持执行恶意代码。这提醒用户，托管服务的安全加固层可能并不如预期可靠。
跨租户攻击的威胁模型与厂商应对差异
文章将跨租户攻击分为三类：Web UI漏洞、间接访问（如备份存储配置错误）以及通过Postgres实例攻击底层基础设施。作者发现，不同厂商对安全加固扩展绕过漏洞的态度差异很大：有的不认为这是漏洞且不支付赏金，有的则积极修复。这种差异反映了厂商对隔离层信任程度的不同，也意味着用户在选择托管服务时需关注厂商的安全响应策略。
LANGUAGE internal：绕过文件读写限制的关键
即使安全扩展阻止了lo_export等危险函数，攻击者仍可利用LANGUAGE internal创建函数，并通过更新pg_catalog.pg_proc.prosrc将其指向内部函数（如be_lo_export），从而绕过黑名单实现文件写入。文章指出，没有厂商在扩展层面阻止LANGUAGE internal，而PostgreSQL核心团队认为这属于服务商责任。最终，攻击者可结合LANGUAGE C加载恶意共享库，实现远程代码执行。
安全边界与责任划分的思考
文章强调，安全加固扩展的绕过漏洞是否构成“漏洞”，取决于威胁模型中的安全边界。对于Google Cloud等厂商，默认用户已拥有实例内所有数据库的读写权限，提升为超级用户并未显著扩大数据访问能力，因此他们更关注低权限用户到超级用户的提升。作者认同PostgreSQL核心团队的立场：如果利用未跨越安全边界，则只是bug。这提示用户需理解服务商定义的安全边界，并据此评估风险。
Q&A
什么是PostgreSQL安全加固扩展？它的主要目标是什么？
安全加固扩展是托管PostgreSQL服务商用来限制超级用户权限的扩展。它们有两个主要目标：1) 锁定超级用户角色，防止用户获得超级用户权限；2) 阻止危险函数（如lo_export、pg_read_file或FROM PROGRAM）被调用，即使对超级用户也禁止，以防止与底层操作系统交互。
攻击者如何利用FDW验证器绕过安全加固扩展提升至超级用户？
安全加固扩展在处理CREATE FOREIGN DATA WRAPPER时，会临时将当前用户切换为超级用户，然后将原始语句交给PostgreSQL核心执行。但扩展没有验证函数OID，攻击者可以创建一个恶意验证器函数，当扩展提升权限后，PostgreSQL会以超级用户身份调用该验证器，从而执行恶意代码（如创建超级用户角色）。
search_path劫持如何导致权限提升？
在权限提升窗口期间，当前用户变为超级用户，search_path中的$user会解析为超级用户模式（如postgres）。攻击者可以在postgres模式下创建同名函数，当扩展将语句交给PostgreSQL核心重新解析时，会解析到攻击者控制的函数，从而以超级用户身份执行恶意代码。
LANGUAGE internal如何被用来绕过文件读写限制？
攻击者可以创建一个LANGUAGE internal函数，然后更新pg_catalog.pg_proc中的prosrc字段，将其指向内部函数如be_lo_export。这样就能绕过对lo_export等函数的黑名单限制，实现文件写入。之后可以写入恶意共享库，并通过LANGUAGE C加载执行，最终实现远程代码执行。
托管PostgreSQL服务面临的主要威胁模型是什么？
主要威胁是跨租户攻击，即一个Postgres客户能够访问另一个客户的租户。攻击者可能通过产品管理Web UI的漏洞、间接跨租户访问（如备份、存储配置错误）或通过Postgres盒子攻击基础设施（如利用COPY TO/FROM PROGRAM执行操作系统命令）来实现。
作者在安全加固扩展中发现了多少个漏洞？涉及哪些厂商？
作者共报告了76个与安全加固扩展相关的漏洞。涉及的厂商包括Azure、Aiven、Supabase、PlanetScale、Xata.io、AWS Aurora、Google AlloyDB和NeonDB等。
PostgreSQL核心安全团队对LANGUAGE internal漏洞的立场是什么？
PostgreSQL核心安全团队承认允许用户创建LANGUAGE internal函数会使其控制服务器，但他们认为主要托管提供商不太可能暴露此功能，除非已经授予完全超级用户访问权限。他们建议将此类问题报告给受影响的服务提供商，因为修复责任在于提供商而非核心团队。
