[Paper] FuzzySQL：利用LLM驱动的模糊测试揭示DBMS特性中的隐藏漏洞

发布: 3天前 (2026年2月23日 GMT+8 12:20)

7 分钟阅读

原文: arXiv

Source: arXiv - 2602.19490v1

概述

FuzzySQL 是一个新型的模糊测试框架，利用大语言模型（LLM）生成并变异 SQL 语句，以揭示现代数据库管理系统（DBMS）“特殊”功能中的隐藏缺陷。通过超越普通查询语法，针对诸如 GTID、存储过程和进程控制语句等少用指令，作者展示了许多关键漏洞对传统模糊测试工具仍然不可见。

LLM‑驱动的 SQL 生成 – 将基于语法的种子生成器与能够推理 SQL 语义并生成真实、功能丰富语句的大型语言模型相结合。
逻辑转移的渐进突变 – 一种新颖的突变策略，可翻转条件、重构控制流，并迫使 DBMS 走向替代执行路径。
混合错误修复流水线 – 使用规则基补丁和 LLM 引导的语义修复自动修复语法和上下文相关的失败，使模糊测试循环保持活跃。
跨 DBMS 评估 – 应用于 MySQL、MariaDB、SQLite、PostgreSQL 和 ClickHouse，发现 37 个此前未知的漏洞，其中 7 个与未充分测试的特殊功能相关。
真实世界影响 – 已确认 29 个漏洞，分配了 9 个 CVE 编号，已有 14 个补丁由厂商发布。

Grammar‑Guided Seed Creation – 传统的 SQL 语法生成覆盖常见 DML/DDL 模式的基线查询。
LLM‑Assisted Enrichment – 大型语言模型（例如 GPT‑4）使用罕见的构造（例如 SET GLOBAL GTID_PURGED、CALL PROCEDURE、KILL QUERY）扩展这些种子。模型会被提示遵循目标 DBMS 的方言。
Logic‑Shifting Progressive Mutation – 与简单的标记交换不同，框架系统性地否定谓词（WHERE x > 5 → WHERE NOT (x > 5)）、交换分支并注入控制流语句，迫使引擎探索替代的执行路径。
Hybrid Error Repair – 当生成的查询无法解析或违反运行时约束时，会启动两阶段修复：
- Rule‑based patcher 修复明显的语法错误（缺少逗号、引号不匹配）。
- LLM‑semantic fixer 重写查询以满足上下文需求（例如添加缺失的权限、纠正数据类型不匹配）。
Instrumentation & Crash Detection – 模糊测试框架监控进程退出、sanitizer 警报和 DBMS 日志，以捕获崩溃、内存损坏或安全相关的错误信息。

循环重复进行，不断将成功的变体反馈给 LLM，以实现进一步的多样化。

DBMS	发现的漏洞数量	已分配的 CVE	供应商已修复
MySQL	12	4	5
MariaDB	8	2	3
SQLite	5	1	2
PostgreSQL	7	1	2
ClickHouse	5	1	2

这些发现证实，尽管经过多年加固，DBMS 仍然潜藏着深层的语义级别漏洞。

Security‑first development – 构建依赖高级 DBMS 功能（复制、自定义存储过程、多租户隔离）的应用团队应将语义模糊测试纳入 CI 流水线，而不仅仅是语法 SQL 验证。
Vendor tooling – 数据库厂商可以采用逻辑迁移变异策略来改进内部回归套件，尤其是针对新加入的系统级命令。
LLM‑assisted testing – 混合修复流水线展示了一种在不让开发者被误报淹没的前提下，让 LLM 持续参与测试的实用方式；类似模式同样适用于其他复杂配置语言（例如 Kubernetes YAML、Terraform）。
Compliance & Auditing – 发现隐藏的特权提升路径帮助组织满足 PCI‑DSS、ISO 27001 等标准的要求，这些标准要求对未记录的 DBMS 能力进行审计。

简而言之，FuzzySQL 表明，对 LLM 驱动的模糊测试进行适度投入即可揭示那些否则会隐藏多年、影响巨大的缺陷。

LLM 依赖 – 生成查询的质量取决于底层模型；较小或较旧的模型可能会遗漏细微的方言差异。
资源密集 – 大规模运行 LLM 推理会增加 CPU/GPU 开销，对小团队可能构成阻碍。
覆盖空白 – 虽然特殊功能得到更好地测试，但某些 DBMS 特定的扩展（例如自定义插件、用户自定义函数）仍未涵盖。
未来方向：作者提出的建议包括：结合强化学习以优先选择历史上导致崩溃的变异、将框架扩展到 NoSQL 存储、以及开源轻量级的 “LLM‑lite” 变异引擎以促进更广泛的采用。