PostgreSQL pgcrypto 堆缓冲区溢出漏洞 CVE-2026-2005 深度分析
漏洞分析
本文深度分析 PostgreSQL pgcrypto 扩展的堆缓冲区溢出漏洞 CVE-2026-2005（CVSS 8.8）。漏洞存在于 PGP 公钥解密会话密钥解析函数，攻击者仅需低权限 SQL 查询即可触发堆溢出，进而劫持 MemoryContext 虚函数表实现任意命令执行，潜伏 20 年方被修复。文章从补丁 diff 源码走读出发，拆解三阶段利用链，覆盖影响版本、修复方案、检测规则及真实复现踩坑记录。
一、前言 ---- PostgreSQL 在 2026 年 2 月 12 日发了一个安全更新，五个大版本同时修了一个洞——CVE-2026-2005，CVSS 8.8，评的是 HIGH。 这个洞在 pgcrypto 扩展里。pgcrypto 是 PostgreSQL 的加密模块，提供 PGP 加解密、哈希、对称加密这些功能。很多生产环境都装了它，因为它是一个 trusted extension——任何有 CREATE 权限的数据库用户都能装，不需要 superuser。 漏洞点出在 PGP 公钥解密的 session key 解析过程。攻击者构造一段恶意 PGP 密文，丢给 `pgp_pub_decrypt_bytea()`，就能触发堆缓冲区溢出。溢出发生在 `PGP_Context` 结构体内部，数据一路写穿到相邻的堆分配块，最终可以篡改 PostgreSQL 的 MemoryContext 虚函数表指针。 说白了：一条 SQL 查询就能拿 shell，权限是跑 PostgreSQL 的那个 OS 用户。 这篇文章从补丁 diff 出发，做一遍完整的源码走读和利用链分析。 二、pgcrypto 背景：PGP 公钥解密流程 ------------------------ 要理解这个洞，得先搞懂 pgcrypto 是怎么处理 PGP 公钥解密的。 PGP 公钥解密涉及两种密钥。RSA/ElGamal 公钥太慢，不会直接拿它加密消息体。实际的流程是： 1. 发送方随机生成一个 session key（对称密钥，比如 AES-128 的 16 字节） 2. 拿 session key 加密消息体 3. 拿接收方的 RSA 公钥加密这个 session key 4. 两个东西打包成一个 PGP 消息发出去 接收方收到后反过来： 1. 用自己的 RSA 私钥解密出 session key 2. 拿 session key 解密消息体 PGP 消息里，RSA 加密后的 session key 包在一个 **Public-Key Encrypted Session Key Packet**（Tag 1）里。关键的代码就在这里。  在 PostgreSQL 里，对外的入口是 `pgp_pub_decrypt_bytea()` 这个 SQL 函数。调用它只需要两条 SQL： ```sql CREATE EXTENSION IF NOT EXISTS pgcrypto; SELECT pgp_pub_decrypt_bytea(密文::bytea, 私钥::bytea); ``` 函数内部会调用 `decrypt_internal()`，后者解析 PGP 消息结构，碰到 Tag 1 包就转给 `pgp_parse_pubenc_sesskey()` 处理。问题就出在这个函数里。 **说白了：攻击者只需要能执行 SQL 查询就能走到漏洞点。不需要 superuser，不需要特殊的 GRANT。** 三、漏洞根因：pgp\_parse\_pubenc\_sesskey 源码走读 --------------------------------------- ### 3.1 受影响代码位置 文件：`contrib/pgcrypto/pgp-pubdec.c` 函数：`pgp_parse_pubenc_sesskey()` 这个洞存在了 20 年——从 pgcrypto 最初被贡献进 PostgreSQL 代码库的那天就在。 ### 3.2 数据流追踪 把调用链展开看： ```php pgp_pub_decrypt_bytea(密文, 私钥) ← 攻击者入口 → decrypt_internal() → pgp_parse_pubenc_sesskey(ctx, pkt) ← 处理 Tag 1 包 → RSA/ElGamal 解密，得到 msg 和 msglen → ctx->sess_key_len = msglen - 3 ← 长度来自攻击者控制的密文 → memcpy(ctx->sess_key, msg+1, ...) ← 漏洞点！ ``` `sess_key` 的定义在 `PGP_Context` 结构体里： ```c // contrib/pgcrypto/pgp.h uint8 sess_key[PGP_MAX_KEY]; // PGP_MAX_KEY = 32 ``` 固定 32 字节。而 `msglen - 3` 是多少？取决于攻击者的 RSA 密文解密后的数据长度。一个 2048 位的 RSA 密钥，解密后能产出最多 256 字节的明文。如果攻击者把 session key 做得很大——减去 PKCS#1 v1.5 的 padding 开销，轻松超过 32 字节——那 `memcpy` 就会写穿。 ### 3.3 补丁对比 下面是 PostgreSQL 官方修复 commit `379695d3` 的核心变更。只改了 11 行： ```c // === 修复前（漏洞代码）=== /* got sesskey */ ctx->cipher_algo = *msg; ctx->sess_key_len = msglen - 3; memcpy(ctx->sess_key, msg + 1, ctx->sess_key_len); // === 修复后 === unsigned sess_key_len; // ... RSA/ElGamal 解密代码 ... sess_key_len = msglen - 3; if (sess_key_len > PGP_MAX_KEY) { px_debug("incorrect session key length=%u", sess_key_len); res = PXE_PGP_KEY_TOO_BIG; goto out; } /* got sesskey */ ctx->cipher_algo = *msg; ctx->sess_key_len = sess_key_len; memcpy(ctx->sess_key, msg + 1, ctx->sess_key_len); ``` 改动很简单：引入局部变量 `sess_key_len`，在 `memcpy` 之前加了一个 `if (sess_key_len > PGP_MAX_KEY)` 的边界检查。超了就报错 `"Public key too big"` 然后跳走。 新增错误码： ```c // px.h: PGP_MAX_KEY 附近 #define PXE_PGP_KEY_TOO_BIG -111 // px.c: 错误信息映射表 {PXE_PGP_KEY_TOO_BIG, "Public key too big"}, ``` 补丁同时加了一套回归测试（`pgp-pubkey-session.sql` + 数据生成脚本 `pgp_session_data.py`），用的是第二个 Tag 1 包构造超长 session key 来触发检查。 ### 3.4 为什么 20 年没人发现 这个函数本身不长，逻辑也直白。但问题是它藏在一个 contrib 模块里，日常代码审查的注意力一般不在这些"附加功能"上。而且 pgcrypto 的用户——用 PGP 加密存储敏感字段的人——确实不太多，这个攻击面比较隐蔽。 更关键的是，单独看这一行 memcpy，"溢出了 32 字节的数组"好像就是个 crash。但从利用的角度看，这 32 字节的 sess\_key 后面紧挨着的内存布局才是真正要命的东西。 **一句话：一个漏掉的边界检查，让攻击者拿到了整个堆布局的控制权。** 四、利用分析：从堆溢出到 RCE ---------------- ### 4.1 堆布局：为什么这个溢出刚好可控 溢出的破坏力取决于被溢出缓冲区后面是什么。在 `decrypt_internal()` 里，`PGP_Context` 是通过 `palloc0()` 分配的，紧挨着它还有两个 `MBuf` 结构体——`src`（输入缓冲区）和 `dst`（输出缓冲区）。 ```php 堆内存布局（decrypt_internal 内分配）： ───────────────────────────────────────────────────── │ PGP_Context ctx │ 184 字节 (palloc chunk=256) │ sess_key[32] 在 +148 │ ← 溢出的起点 ├────────────────────────┤ │ [chunk padding] │ 72 字节 ├────────────────────────┤ │ MemoryChunk header │ 8 字节 (ctx+256) │ MBuf src (64B chunk) │ ← 第一个被溢出覆盖的结构 ├────────────────────────┤ │ MBuf dst (64B chunk) │ ← 第二个被覆盖，关键控制点 └────────────────────────┘ ```  `sess_key` 在 PGP\_Context 的偏移 148 处。从这开始往高地址写，可以精准覆盖 `src` 和 `dst` 两个 MBuf 的 header 和 data 指针。 PostgreSQL 用的是 fork 模型——每个客户端连接 fork 一个 backend 进程，继承父进程的地址空间。这意味着 ASLR 布局在同一个 postmaster 的所有连接之间是**完全相同**的。一次连接里泄漏的地址，在下一次连接里仍然有效。 ### 4.2 三阶段攻击链 完整的利用分三步，都在同一条 PGP 消息里完成。消息结构是 `PKESK + SED + PKESK`——第一个 Tag 1 包正常解密，第二个 Tag 1 包触发溢出。  **阶段一：信息泄漏。** 攻击者构造一个 148 字节的 payload，精确覆盖 `dst` MBuf 的 `data` 指针的低两个字节为 `\x00\x00`。结果 `dst->data` 被拉低，指向了堆的低地址方向。当 `decrypt_internal()` 返回时，`mbuf_steal_data(dst)` 返回的是从被篡改后的 `dst->data` 到原始 `dst->data_end` 之间的一大块堆内存。 这块内存里有什么？PIE 代码段指针、堆地址——ASLR 的随机化就这么被绕过了。一次查询同时拿到了 PIE base 和堆基址。 **阶段二：任意写。** 攻击者开一个新连接（内存布局和上一轮一样），再次触发溢出。这次 payload 完整控制了 `dst` 的四个字段：`data`、`data_end`、`read_pos`、`buf_end`，全部指向目标地址。接着在同一个 PGP 消息里的 `PGP_PKT_SYMENCRYPTED_DATA` 包（对称加密数据包），pgcrypto 会把它解密后的明文写进被篡改过的 `dst`——实现了精确的任意地址写。 **阶段三：提权到 RCE。** 目标是 `CurrentUserId`——PostgreSQL 的全局变量，存的是当前连接认证后的角色 OID。它的值如果是 `10`（`BOOTSTRAP_SUPERUSERID`），PostgreSQL 就认为你是 superuser。 用阶段二的任意写把 `CurrentUserId` 改成 10。然后： ```sql COPY (SELECT '') TO PROGRAM 'id > /tmp/pwned'; ``` Superuser 可以执行 `COPY ... TO PROGRAM`，命令以 postgres 系统用户身份运行。RCE 达成。 ### 4.3 更直接的利用路径：虚函数表劫持 上面那条链依赖 `COPY ... TO PROGRAM`，如果 `COPY PROGRAM` 功能被禁用呢？PoC 里还有一条更直接的路径——MemoryContext 虚函数表劫持。 PostgreSQL 的内存管理基于 MemoryContext 层次结构。每个 MemoryContext 有一个 `methods` 指针，指向一个包含函数指针的结构体（vtable）。关键的两个函数指针： ```php methods->reset() @ offset 24 methods->delete_context() @ offset 32 ``` 利用链的设计思路是：用堆溢出先在 AllocSet 的空闲链表上写一个假块，然后让 PostgreSQL 的 `pfree()` 把这个假块链进去。 关键操作分两步： 第一步，payload 在 `ctx+192` 处写入 `MC-72`，构造一个假的 AllocSet 指针。当 `pfree()` 解码 chunk header 后，`block->aset = *(ctx+192) = MC-72`，系统就以为这个 chunk 属于位于 `MC-72` 地址的 AllocSet。 第二步，`AllocSetFree()` 操作这个假 AllocSet 的 freelist。假 AllocSet 的 `freelist[0]` 字段在 `(MC-72) + 88 = MC + 16`——这个地址恰好就是 `MC->methods` 指针所在的位置。 ```php 假 AllocSet 起始地址： MC - 72（payload 伪造的 aset 指针值） freelist[0] 字段偏移： +88 实际写入地址： MC - 72 + 88 = MC + 16 而 MemoryContextData 中 methods 指针的偏移： +16 → MC->methods 也在 MC + 16 它们完全重叠——写 freelist[0] 等价于改 methods 指针。 ``` `AllocSetFree` 执行 `set->freelist[0] = chunk` 时，把 `ctx+256` 写入了 `MC+16`，也就是把 `MC->methods` 改成了指向 `ctx+256`——攻击者 payload 中伪造的虚函数表。 后续当 pgcrypto 返回错误、PostgreSQL 的错误处理调用 `MemoryContextDelete(MC)` 时： ```c void MemoryContextDelete(MemoryContext context) { MemoryContextDeleteChildren(context); // 子 context 的 methods 没被动，正常 context->methods->delete_context(context); // methods 已经被改成指向攻击者的假 vtable！ } ``` `delete_context` 被劫持到 `system()`，参数 `context` 恰好是 `MC` 的地址。而 `MC` 的第一个字段是 `NodeTag type = T_AllocSetContext = 0x1D5`。在内存中（小端序）就是 `\xd5\x01\x00\x00`——`system()` 读到 `\x00` 就停了，实际执行的命令是 `\xd5\x01`。 如果攻击者提前在 `/usr/local/bin/\xd5\x01` 放了恶意脚本，`system()` 就会通过 PATH 搜索找到它并执行。 ### 4.4 利用条件总结 这一套利用链的实际约束： - 需要已知地址（MC 地址、system() 地址）。在 Docker 镜像里是确定性的，但在不同物理机上需要先信息泄漏或 spray。 - 需要一次 pgcrypto 预热调用（`SELECT digest(...)`）来稳定堆布局。 - Release build 可以打，debug build（`--enable-cassert`）会在 freelist write 完成前触发 assertion 挂掉。 - 需要一个预置的触发脚本或可写的 PATH 目录，或者换一个利用原语（比如 one-gadget）。 **说白了：这洞的利用条件不是"随便打"，但门槛也确实不算高——只需要认证后的一条 SQL 查询，加目标环境的 ASLR 信息。对攻击者来说，PostgreSQL 默认监听 5432 端口，全球有大量直接暴露在公网上的实例。** ### 4.5 复现步骤 #### 详细步骤 1. 拉取镜像（走代理 172.21.192.1:7897） ```php docker pull postgres:17.7-bookworm # 漏洞版 docker pull postgres:17.8-bookworm # 修复版 ```  2. 起漏洞版容器 ```php docker run -d --name pg-vuln \ -e POSTGRES_PASSWORD=labpass -e POSTGRES_DB=lab \ -p 5433:5432 postgres:17.7-bookworm ``` 3. 初始化 ```php docker exec pg-vuln psql -U postgres -d lab -c "CREATE EXTENSION IF NOT EXISTS pgcrypto" docker exec pg-vuln psql -U postgres -d lab -c "CREATE ROLE app LOGIN PASSWORD 'apppass'" ``` 4. 以低权限用户 app 执行 PoC（big 模式，168 字节溢出） ```php docker exec -i pg-vuln psql -U app -d lab < poc_big.sql ```  server直接closed了，容器日志如下  #### 结果对比 漏洞版 PostgreSQL 17.7（修复前） psql 输出： ```php Timing is on. server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. connection to server was lost ``` 容器日志： ```php LOG: server process (PID 108) was terminated by signal 11: Segmentation fault LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing LOG: database system was interrupted; last known up at ... LOG: database system was not properly shut down; automatic recovery in progress ``` → **堆溢出触发，backend 进程 SIGSEGV 崩溃，数据库自动恢复重启** 修复版 PostgreSQL 17.8（补丁后）  ```php psql 输出： Timing is on. ERROR: Public key too big Time: 2.263 ms ``` → **新增边界检查生效，恶意 session key 长度被拦截，无崩溃** 验证要点 1. **低权限触发确认**：以普通用户 `app`（非 superuser）执行即可触发崩溃 2. **PGP 数据处理确认**：minimal 模式（4 字节溢出）不崩溃返回 `\x0a00`，big 模式（168 字节）崩溃 → 溢出量超过 chunk padding 才破坏相邻结构 3. **补丁签名确认**：17.8 返回 `ERROR: Public key too big`（对应新增错误码 PXE\_PGP\_KEY\_TOO\_BIG = -111） ### 4.6 RCE 复现 从堆溢出到命令执行的完整链路在 4.2/4.3 已经做了理论拆解，这里放完整的 RCE 复现过程。复现需要解决的核心问题是**运行时地址校准**——溢出 payload 里要写入两个绝对地址（`MC-72` 和 `system()`），而 PostgreSQL 的 MemoryContext 是运行时分配的，不同环境、不同启动实例的值都不一样，不能写死。  复现环境的关键参数： | 参数 | 说明 | 获取方式 | |---|---|---| | `libc base` | glibc 基址 | `/proc/<postmaster_pid>/maps` | | `system()` | libc base + 0x4c490（glibc 2.36） | 符号表 | | `MC-72` | MemoryContextDelete 清理的 context | 运行时校准（见 4.7） | **一句话：RCE 复现 = 崩溃复现（4.5）+ 地址校准 + vtable 劫持三步，缺一不可。** ### 4.7 踩坑分享 复现过程中踩了不少坑，很多坑不是漏洞本身的问题，而是环境与工具链的，写出来供参考。 **触发脚本的文件名被 Dockerfile 转义机制吃掉了。** RCE 的最后一步是 `system()` 执行 `/usr/local/bin/\xd5\x01`（字节 0xd5 0x01），仓库的 `Dockerfile.exploit` 用这条命令创建触发脚本： ```dockerfile RUN printf '#!/bin/sh\nid > /tmp/pwned\n' \ > "/usr/local/bin/$(printf '\xd5\x01')" ``` 看着没问题，但 Dockerfile 的转义机制会把 `\x` 里的反斜杠吃掉——`\xd5` 变成 `xd5`，最终创建出来的文件名是 **`xd5x01`（普通文本）**，而不是字节 `0xd5 0x01`。`system()` 按字节名去找命令，永远找不到，RCE 静默失败。 排查过程很费劲：`ls` 看文件名是 `\xd5\x01`，还以为是字节名（`cat -v` 的显示有迷惑性），用 `od` 看实际字节才发现是文本。修复方式是用 python 创建字节名文件： ```python import os path = b'/usr/local/bin/\xd5\x01' open(path, 'wb').write(b'#!/bin/sh\nid > /tmp/pwned\n') os.chmod(path, 0o755) ``` 五、影响范围与修复 --------- ### 5.1 受影响版本 这个洞影响 PostgreSQL 所有仍在支持的大版本： | 大版本 | 受影响版本 | 修复版本 | |---|---|---| | 18.x | < 18.2 | 18.2 | | 17.x | < 17.8 | 17.8 | | 16.x | < 16.12 | 16.12 | | 15.x | < 15.16 | 15.16 | | 14.x | < 14.21 | 14.21 | 五个大版本在 2026 年 2 月 12 日同步发布了修复。 漏洞代码自 pgcrypto 模块在 2005 年被合入 PostgreSQL 主仓库时就存在，横跨了整整 20 年。这意味着 EOL 的版本（13 及以下）虽然没有官方补丁，但同样受影响的概率极高。 ### 5.2 攻击面评估 pgcrypto 是一个 **trusted extension**。在 PostgreSQL 的扩展安全模型里，trusted 意味着任何拥有数据库级别 CREATE 权限的用户都能安装它，不需要 superuser。 `pgp_pub_decrypt_bytea()` 的 EXECUTE 权限默认授予 PUBLIC——换句话说，只要能连上数据库、能执行 SQL 的角色，就能调用这个有漏洞的函数。 攻击面主要在这几个场景： - 直接暴露在公网的 PostgreSQL 实例（互联网测绘数据显示数量可观） - 应用层 SQL 注入点，能拼接任意查询 - 内网横向移动——攻破一台应用服务器后，上面配置了数据库连接凭据 ### 5.3 修复方案 **首选：升级到修复版本。** 18.2、17.8、16.12、15.16、14.21 任选对应的。 如果短期升不了，临时缓解： 1. 收回 `pgp_pub_decrypt_bytea()` 的 PUBLIC 权限： ```sql REVOKE EXECUTE ON FUNCTION pgp_pub_decrypt_bytea(bytea, bytea) FROM PUBLIC; REVOKE EXECUTE ON FUNCTION pgp_pub_decrypt_bytea(bytea, bytea, text) FROM PUBLIC; REVOKE EXECUTE ON FUNCTION pgp_pub_decrypt_bytea(bytea, bytea, text, text) FROM PUBLIC; ``` 2. 如果不需要 pgcrypto，直接删掉： ```sql DROP EXTENSION pgcrypto; ``` 3. 网络层限制数据库连接来源，特别是禁止公网直接暴露 5432 端口。 六、防御与检测 ------- ### 6.1 SQL 层面的审计规则 如果你有数据库审计系统（pgAudit 或者应用层 SQL 日志），可以重点监控以下模式： ```sql -- 监控 pgcrypto 扩展的安装 SELECT * FROM pg_available_extensions WHERE name = 'pgcrypto'; -- 监控公钥解密函数的调用 SELECT pgp_pub_decrypt_bytea(...); -- 监控 COPY PROGRAM 的使用（利用链的最后一环） COPY ... TO PROGRAM ...; COPY ... FROM PROGRAM ...; ``` pgAudit 配置示例： ```ini # postgresql.conf shared_preload_libraries = 'pgaudit' pgaudit.log = 'write,role,ddl,function' pgaudit.log_level = 'warning' ``` 上面这个配置会记录所有写操作、角色变更、DDL 和函数调用——正好覆盖了这条链的三个关键步骤。 ### 6.2 主机层检测 如果你的环境能用 Falco 或者 auditd，下面几个检测规则比较实用： ```php # Falco 规则：检测 PostgreSQL 进程的异常子进程 - rule: PostgreSQL spawns shell condition: proc.pname = "postgres" and proc.name in (sh, bash, dash, zsh) output: "PostgreSQL spawned a shell (user=%user.name cmd=%proc.cmdline)" priority: CRITICAL - rule: COPY PROGRAM execution condition: proc.pname = "postgres" and spawned_process output: "PostgreSQL executed external program (cmd=%proc.cmdline)" priority: WARNING ``` PostgreSQL 正常情况下不应该执行外部命令——除非用了 `COPY ... TO PROGRAM`。postgres 进程 fork 出 shell 几乎一定是异常行为。 ### 6.3 网络层 pgcrypto 函数调用在 SQL 层面看起来就是一次普通的查询，WAF 不太可能从网络流量里区分出恶意 PGP 密文和正常密文。所以网络层的策略重点是**访问控制**而不是 payload 检测： - PostgreSQL 端口不对外开放，放在 VPN/专线后面 - 应用层使用连接池 + 最小权限账号，不要给应用账号 superuser 或 CREATEROLE 权限 - 定期审计 `pg_user` 和 `pg_auth_members` 中的权限分配 **一句话：这个洞的防御重点不在流量侧，在权限和审计。** 七、总结 ---- CVE-2026-2005 是个教科书级的堆溢出漏洞。根因简单到一句话就能说完——`memcpy` 之前没检查长度。但它的利用链展现了 PostgreSQL 内部内存管理机制的多个可被滥用的特性：确定性的堆布局、fork 共享地址空间、MemoryContext 的虚函数表设计。 我自己的几个想法： 1. **contrib 模块的安全审计是个盲区。** pgcrypto 在 contrib 目录下躺了 20 年。核心代码的每一行都被反复审查过，但 contrib 模块——特别是那些不常被用到的函数——可能藏着更多的坑。 2. **trusted extension 的安全模型值得重新审视。** pgcrypto 被标记为 trusted，意味着非 superuser 也能安装。但它的功能（加密/解密、密钥处理）涉及 C 级别的缓冲区操作。让低权限用户安装 C 扩展，不管它是不是 "trusted"，都增加了攻击面。 3. **PostgreSQL 的 fork 模型对 ASLR 不友好。** 这是为了性能（共享内存、写时复制），但从安全角度看，一次信息泄漏就让整个 postmaster 的所有连接失去了 ASLR 保护。这个取舍是否合理，可能要看具体场景。 修复本身很简单——三行边界检查。但找出来花了 20 年。
发表于 2026-09-22 09:00:01
阅读 ( 12209 )
分类：
漏洞分析
1 推荐
收藏
0 条评论
zee
11 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
