原文名称：Towards Generic Database Management System Fuzzing
原文作者：Yupeng Yang ,Yongheng Chen, Rui Zhong, Jizhou Chen and Wenke Lee;
原文链接：https://www.usenix.org/system/files/usenixsecurity24-yang-yupeng.pdf
发表期刊：33rd USENIX Security Symposium
开源代码：https:// github.com/OMH4ck/BuzzBee.
在现代网络空间中，数据库管理系统（DBMSs）至关重要，其涵盖关系型（SQL）和非关系型（NoSQL）数据库，以满足多样化应用需求。关系型 DBMSs 已被广泛研究和应用数十年，而非关系型 DBMSs 因在处理大规模非结构化数据方面的灵活性和性能优势，近年来也得到广泛采用。鉴于这些系统的普遍性和关键性，强化其安全性与稳健性势在必行。
模糊测试（Fuzzing）作为一种自动化软件测试方法，在发现 DBMSs 缺陷方面颇具成效。然而，针对非关系型 DBMSs 的模糊测试工作相对薄弱。尽管关系型 DBMSs 的模糊测试框架和研究成果丰硕，但非关系型 DBMSs 尚未得到同等程度的审视，现有通用模糊测试框架应用于非关系型 DBMSs 时效果不佳，缺乏能同时有效测试关系型和非关系型 DBMSs 的解决方案。
面对非关系型数据库目前没有一个通用的模糊测试框架。本文深刻分析了对于非关系型数据库使用模糊测试存在的是哪个复杂挑战。
(1)非关系型数据库接口多样性致使难以构建通用框架，在保障测试用例质量的同时兼顾对不同接口的适应性。
(2)非关系型数据库对语义的依赖方式多样，且语义随上下文变化明显。针对不同的非关系型数据库，对生成的中间表示（IR）进行语义约束十分困难。
(3)随机变异易产生松散数据依赖，触发低效测试行为，而数据依赖在有效模糊测试中起着关键作用。
为应对上述挑战，构建针对通过非关系型数据库的专用模糊测试工具，本文提出语义抽象、上下文敏感约束解析和依赖引导变异三项解决方案，并将其整合到端到端模糊测试框架BuzzBee中。
该框架能够有效测试多种类型的 DBMSs，在八个不同数据模型的 DBMSs 中成功发现 40 个漏洞，其中 25 个已修复且 4 个被分配新的 CVE 编号。在评估中，BuzzBee 在代码覆盖率方面相比现有最佳通用模糊器提升高达 177%，在非关系型 DBMSs 测试中发现的漏洞数量比次优模糊器多 30 倍。在关系型 DBMSs 测试中也能取得与专业 SQL 模糊器相当的结果。
![Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试]( "Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试")
图 1 BuzzBee流程图
工具整体的测试流程如图1所示。用户输入的文件包括Corpus和Input-Specs两个部分。然后工具根据Input-Specs中的g4语法文件和初始种子用例使用 ANTLR4 语法对输入的测试用例进行解析，基于语法规则构建抽象语法树（AST）。同时，利用注释文件中的信息对AST 节点进行标注。注释文件通过语法标签将语法规则中的元素与语义信息相关联，用户可以为不同的语法结构指定如定义（Define）、使用（Use）、失效（Invalidate）等基本语义操作以及相关的约束信息（如数据类型等）。这些标注信息为后续生成中间表示（IR）提供了语义基础。然后生成语法结构完整的IR，并放入工具设计的注释系统（Annotation system）中，在注释系统中，工具根据用户提供的Input-Specs的语义json文件和工具设计的上下文查询语言（CQL）或用户自定义的操作（Custom Resolver）对IR实现紧凑的语义数据依赖。根据引导性变异器实现完全保证语法正确并尽量保证语义正确（在先前数据库模糊测试工具SQUIRREL中已经解释实现完全语义正确是np问题）的测试用例。然后语义检查系统对测试用进行最后的语义检查，有语义错误的尽量修改，否则丢弃。最后通过整个流程的IR会被放入模糊测试器进行测试。然后根据feedback对初始种子进行更新，同时对引导变异器的原则进行自适应调整。接下来是对每个部件的详细介绍。
如图2，以对redis键值对数据库为例，示例选取了仅仅包括HSET和HINCRBY两个key的初始种子用例。初始种子用例都是语法语义正确的可被数据库接受的输入。这些初始的测试用例都有用户提供。后续经过每轮模糊测试都都会自动更新。
图 2 初始种子图例
图3所示的是语法语义的约束文件。左边的是语法约束文件。其中示例定义了HSET的语法规则，并以HSET语法为例做一下详细解释。HSET0定义了顶层规则，表示整个HSET命令的结构。它由HSET1（命令名），HSET3（哈希键），HSET4（字段），HSET5（值）以及HSET6（可能包含多个字段和字段值的组合）组成。其中可以看到在HSET3和HSET4与HSET8后的元素字段后加上了#HSETRule1和#HSETfield1等这样的字段。这是工具需要的语法标签（grammar tag)。这是标记这个语法点的记号，方便用户后续在使用注释系统时对这个记号点的值进行语义的定义。具体的语义注释系统将会在后续章节介绍。这样的语法规则是基于现有工具ANTLR4的定义规则要求的，现有很多开源的常用数据库的这种g4语法规则文件，用户只需按照需求下载后对所需的语义点打上grammar tag并为其写上语义文件即可。
图3右图所展示的是语义语法规则。如语法规则中的HSET3，HSET4和HSET8中分别打了一个grammar tag，其作用是给用户自定义该键值位置语义规则。语义规则由用户使用json文件自定义。包括三个内容action，args和ast_context。其具体含义会在后续内容（构建中间表示和注释系统）中详细介绍。
图 3 语法语义约束文件
构建中间表示IR首先根据用户提供的g4语法文件使用 ANTLR4 语法对输入的测试用例进行解析，基于语法规则构建抽象语法树（AST）。同时，利用注释文件中的信息对 AST 节点进行标注。注释文件通过语法标签将语法规则中的元素与语义信息相关联，用户可以为不同的语法结构指定如定义（Define）、使用（Use）、失效（Invalidate）等基本语义操作以及相关的约束信息（如数据类型等）。这些标注信息为后续生成 IR 提供了语义基础。
定义（Define）：表示数据创建。例如，在图 4c 中，第一个 Redis 命令 HSET 定义了类型为 HSET key 的数据 k1 以及类型为 HSET field of k1 的 k1_field1。类似地，在图 1a 中，PostgreSQL 查询 CREATE TABLE 定义了两个数据：类型为 table 的 t1 和类型为 col_of_t1（表示 t1 的列）的 c1。需要注意的是，这些数据可能存在从属关系，例如 k1_field1 从属于 k1，意味着没有 k1 就不存在 k1_field1。同样，t1 和 c1 也存在这种关系。这种关系可以通过本文的上下文查询语言（CQL）和自定义解析器进行建模，稍后将详细介绍。其基本思想是在数据类型中包含具体的符号名称，例如 k1_field 的类型为 HSET field of k1，其中包含了具体符号名称 k1，表示 k1_field 与 k1 相关联。这时就很容易理解图3右图部分语义规则约束的action的用意了。HSET在redis数据库中是创建命令，所以action为定义。同理对于SQL关系型数据库，键值create也是定义操作，action也会赋值为define。
图 4 不同类别数据库执行语句示例图
使用（Use）：表示对已定义数据的访问和更新操作。例如，图4c 中第 4 行和第 8 行的 HINCRBY 命令使用了由两个 HSET 命令定义的数据 k1、k1_field1、k2 和 k2_field1。使用未定义的数据被视为语义错误。同样，对于redis数据库，HINCRBY命令是对于已经定义的key进行值的加减操作，故其语义action应该设置为use，对于SQL类数据库，例如select语句，其语义aciton也就是use。
失效（Invalidate）：表示对已定义数据的删除操作。一旦数据被失效，就不能再次使用。需要注意的是，数据删除应遵循从属关系。例如，在图 4c 中，如果取消注释第 7 行的 DEL 命令，它将删除 k2。由于k2_field1 与 k2 存在从属关系，k2_field1 也应被删除。同样，在图4a 中，如果删除表 t1，其列 c1 也应被删除。在执行失效操作后，对已失效数据的任何使用都将被视为语义错误。因此，如果取消注释图 1c 中第 7 行的 DEL 命令，第 8 行将会产生两个语义错误，因为 k2 和 k2_field1 都已被失效。同理对于SQL类数据库，例如delete语句，其语义action也应该定义为Invalidate。
如图6所示，这是一个简单是初始种子和语法语义文件。其中在语法文件中grammar tag以①形式简化。对于③我们可以看到这是HSET操作的key，所以type就是HSET-key。而对于④，是key值得一个具体的field。他的type定义是HSET numeric field of {.lsib(1)@text}。这个表达式的意义需要结合文章提出的CQL上下文查询语言来理解。例如对于图6中的左图第5行HINCRBY语句，假设已经构建好的IR如图5中的抽象IR，最下面一行表示的是这个语句在抽象语法树中的形式。.lsib(1)是指查找该节点的第一个左兄弟节点。是作为导航器。此时就找到了key节点，然后@text表示读取该节点的内容，即读取到了k1。如此原理根据CQL语言解析后，k1_field1的type定义就是HSET numeric field of k1。这是一种简单有效的标记语义的方式。但同时作者也注意到，使用这种简单的硬编码方式对于一些复杂的语义场景是不具有兼容性的。于是作者同时设计了一个用户自定义操作。需要用户自己用C语言实现。例如②，type中的是hset_field_type_resolver。这是一个用户用C语言自定义的操作，其具体操作是首先导航到field的.rlib(1)，读取value的值。如果value的值是数字类型则返回HSET numeric field of {.lsib(1)@text}，否则返回HSET field of {.lsib(1)@text}。根据上文描述，我们已经知道{.lsib(1)@text}表示读取左边第一个节点的值。接下来看图6中的第一行和第二行代码。HSET kl k1_field1 “Hello”，对于k1_field1，读取value值，及Hello，非数字，返回，HSET field of {.lsib(1)@text}。所以k1_field1的type是HSET field of k1。同理可得k2_field1的type是HSET numeric field of k2。后续的引导性变异过程中进行节点替换时，如果将k1_field1和k2_field1相互替换将导致语义错误，因为二者的类型不一样。这样做的意义是在避免这类语义错误。
在每次模糊测试的迭代过程中，PromptFuzz 会探索种子库并更新这些种子程序的质量。利用库 API 的能量反馈和种子质量，PromptFuzz 应用算法1来选择在下一次迭代中使用的新API组合。如果当前迭代中的种子程序不足，PromptFuzz 进入预热阶段（算法1的第3-7行），随机选择高能量API函数以探索之前未发现的库使用。在变异阶段（算法1的第9-23行），PromptFuzz 使用种子程序关键路径上的API调用序列作为变异的枢纽，丢弃那些不与其他API调用交互的调用。将变异集中在枢纽上，使PromptFuzz能够探索复杂的API使用。最后，PromptFuzz 使用新的API组合构建下一次程序生成的提示。
图 6 语义解析示例图
引导性变异器也是这篇文章的一个重要设计组件之一。其目的是通过变异测试用例来探索DBMS 的更多行为并发现潜在漏洞，遵循依赖引导变异原则，以数据依赖为指导优先选择能形成新数据依赖的变异操作，同时保持语法正确性。由于在变异之前已经实现了构建语法正确的抽象语法树（AST），在变异过程中为了保证测试用例的语法语义正确，作者主要使用三种变异手段，包括节点替换、插入和删除。
具体实现过程中首先需要从输入与信息获取，从语义分析器获取提升后的 IR 程序作为输入，获取其中的符号和作用域信息等。接下来从三种变异操作中选取来对测试用例进行变异。节点替换是指优先选择与当前节点已定义且未失效的符号相关的节点进行替换，这些符号能与测试用例中的现有符号形成依赖关系，触发更深层次的程序状态。比如在处理数据库操作命令时，若要替换某个节点，会从 IR 池中选择包含相关使用或失效操作的节点。节点插入遵循与节点替换类似的逻辑，找到合适的节点进行插入以形成新的数据依赖。节点删除就是随机选择一些语句的关键字进行删除，当然，为了保证语义的正确性，有相关依赖的语句也要同时删除。还是以redis数据库为例。对于节点的替换，以初始命令HSET k1 k1_field1 1为例，可能的变异操作包括将HSET节点替换为HINCRBY节点，利用之前创建的数据形成新的数据依赖，触发增加数据的操作；同样对于节点的插入，还是假设现在有HSET k1 k1_field1 1，接下来需要再插入一条命令，由于有语义约束，且工具希望生成的测试用例有紧密的数据依赖，工具希望插入的语句和这个hest定义语句有语义依赖，就只能从Use和Invalidate两个操作中选取一个来对k1进行操作。例如可从IR池中选择的操作包括HINRBY或DEL。至于具体工具会选择哪个操作，会在后续权重分配部分详细介绍。对于节点删除部分，作者目前并未提出一些有指导性的删除策略，就是对一些节点进行随机删除，如果破坏了语义信息，后续会有语义检查和语义修复组件，当然删除也需要根据语义依赖进行删除。例如语句HSET k1 k1_field1 value1 k1_field2 value2，假设此时变异器决定对k1_field2节点进行删除，由于value2也是语义依赖k1_field2的，所以value2也将同时被删除。即节点删除后的语句变成HSET k1 k1_field1 value1。
上述介绍的是具体的变异操作，而具体的的变异选择工具遵循行为覆盖优化原则。其原理是根据候选节点是否已存在于测试用例中对其进行优先级排序，为语义动作分配权重，出现次数越多的动作权重越低。这就会指导之前在节点插入部分提到的具体插入哪个语句关键词的问题。例如在图6左上部分第一块，现在要在第4行选择插入的语句。假设HINCRBY和DEL是唯二的选择，而根据行为覆盖优化原则，HINCRBY由于在第5行已经出现，其权重变低，所以工具会选择DEL进行插入（尽管插入后或导致第5行的HINCRBY对一个有已经失效的key进行操作而导致语义错误。这个语义错误会在后续被检查并修复）。这个原则的最终目的是使变异测试用例中不同动作的数量均匀分布，以覆盖更多行为。
总体来说，对于一般的数据库操作，如创建、读取、更新和删除数据的操作序列，变异器会依据数据依赖关系进行优化。若已存在创建数据的操作，会倾向于插入读取或更新该数据的操作，而不是再次创建相同的数据，以更有效地探索数据库行为并发现潜在问题。
语义分析器是根据用户指定的约束来检查抽象语义模型中语义正确性的组件，它通过执行模拟来实现这一目标，该模拟过程包括依赖分析和执行模拟两个阶段。在依赖分析阶段，语义分析器会遍历 IR 程序中的每一个操作，收集每个操作所依赖的上下文，并构建依赖图，然后进行拓扑排序以确定 IR 节点的执行顺序。在执行模拟阶段，语义分析器会按照确定的顺序执行语义操作，对于“定义” 操作，会在当前作用域中定义符号，对于 “使用” 操作，会在作用域树中查找匹配的符号并使用，对于 “失效” 操作，除了执行与 “使用” 操作相同的过程外，还会使符号失效。在这个过程中，语义分析器会评估操作参数中使用的 CQL 查询，并调用自定义解析器来解决特定的值。同时，符号的重新定义、在定义之前使用或在失效之后使用等情况都会被视为语义错误，操作所依赖的上下文包含语义错误时，该操作也会被设置为语义错误。例如，HSET k1 k1_filed1 value1/HMSET k1 k1_filed1 value1。这就是多次定义语义错误。而定义前使用和失效后使用都是例如当前k1值是未定义状态或者已经失效状态后再执行类似于HINCRBY k1 k1_filed1 value1这样类似的Use类的操作。这些都将被视为语义错误来进行处理。
语义分析器会维护符号表和作用域树来跟踪成功执行的操作，并返回所有的符号和作用域信息以及语义错误作为分析结果。最后，语义验证器会在BuzzBee 将测试用例发送到模糊测试器之前，先放入到DBMS系统进行模拟执行，检测语义错误并尝试修复测试用例中的语义错误，例如对于在定义之前使用或在失效之后使用的错误，会寻找其他可用数据来使用，对于重新定义的错误，会尝试用未定义的名称来定义数据，当无法修复错误时，BuzzBee 会放弃这个测试用例。
对于上述提到的整个语义分析，模拟执行和错误纠正流程举一个例子。例如，对于 HSET k1 k1_field1 "Hello" 命令，在语义分析时，首先确定这是一个定义操作（Define），定义了键 k1 及其字段 k1_field1 的值为 "Hello"。此时会检查是否符合定义操作的语义规则，比如键和字段的命名是否合法等。
接着HINCRBY k1 k1_field1 1 命令，这是一个使用（Use）并更新操作，它依赖于前面 HSET 定义的 k1 和 k1_field1。语义分析会检查是否存在对未定义符号的使用，以及操作类型是否与定义的符号类型兼容。在这个例子中，如果 k1_field1 之前被定义为非数值类型（如这里的字符串 "Hello"），那么按照语义规则，HINCRBY 操作在此处就是语义错误的，因为它不能对非数值类型进行自增操作。
这是检测到了这个执行例子存在一个语义错误，语义验证器就会去尝试修改。根据上述提到的修改思路，语义验证器在IR池中找到了例如 HSET k1 k1_field2 1这个语句后，就会用k1_field2去替换之前导致语义出错的k1_field1。这样执行语句将会变为 HINCRBY k1 k1_field2 1。此时满足语义语法规则。当然这只是一个简单的示例，具体现实测试中遇到复杂的情况，语义验证器无法修复的话这个测试用例将会被丢弃。
1．实验设计
硬件环境：在一台运行Ubuntu 22.04.2 LTS 操作系统的机器上进行所有评估，该机器配备两颗AMD EPYC 7452 32 核处理器以及1,024GB RAM。
目标选择：针对三种主流的非关系型数据库（键值、图、文档数据库）和关系型数据库（SQL 数据库）进行评估。具体选取了键值类的redis 和KeyDB、图类的RedisGraph 和AgensGraph、文档类的MongoDB 和ArangoDB、关系型的PostgreSQL 和MySQL。选择依据是其流行程度，并且选择C/C++ 目标是因为当前的模糊测试运行时（AFL++）对其支持最佳。
漏洞挖掘评估：在所选目标的最新发布版本或开发分支上对BuzzBee 进行评估。对 redis、ArangoDB、RedisGraph 和 PostgreSQL 四个目标进行了关于代码覆盖率和漏洞检测能力的综合评估，原因是它们具有较高的模糊测试稳定性且涵盖了所评估的所有四类数据库。同时，将 BuzzBee 与六个先进的模糊测试框架进行比较，包括通用模糊器 AFL++、REDQUEEN、POLYGLOT、Grammarinator 以及专门的 SQL 模糊器 SQUIRREL 和 SQLANCER。在评估过程中，为所有模糊器提供相同的输入（如果需要），并将计算能力限制为一个 CPU 核心。对于漏洞检测评估，将数据库回滚到所有漏洞未修复的版本，每个实验运行24 小时，重复五次，并报告平均结果。
2．实验结果
图 7 对比试验及消融实验结果
项目让每个模糊器运行24 小时并重复五次，报告在此期间它发现的漏洞。图7的左边表格中Property列 “Data” 表示该漏洞需要正确的数据依赖关系才能触发。“Sem” 表示该漏洞不需要数据依赖关系来触发，但触发的测试用例在语义上是正确的。“Syn” 表示该漏洞在语义上不正确但在语法上是正确的。“⊖” 表示该模糊器不支持此数据库管理系统。作者设计的消融实验部分BuzzBee代表功能完善的工具，BuzzBee！g表示没有引导性变异的部分，BuzzBee！gc表示没有引导性变异和上下文敏感约束部分，BuzzBee！gcs表示没有引导性变异，上下文敏感约束部分同时也没有语义抽象部分。
首先看消融实验部分，可以看出，完整的工具找到了最多的bug，而失去引导性变异的工具对于很多data类型的漏洞，及需要强烈数据依赖的漏洞，显得力不从心，但是对于只需要语义正确的sem类型的漏洞还是能够找到。而BuzzBee！gcs工具几乎就不能找到任何类型的漏洞了。但是BuzzBee！gcs 工具找到了一个其他任何消融工具都没有找到的漏洞，对于这个问题作者解释道这个漏洞其实是不符合语义规范的，及不在最开始输入的语义规范定义的json文件里，所以其他的有语义抽象模块的BuzzBee都不能生成这个测试用例。这个漏洞会在后文的bug分析中提到。
接下来看现有工具对比实验测试结果。可以看到对于非关系型数据库，进行测试的AFL++、REDQUEEN、POLYGLOT、Grammarinator 等工具几乎没有找到漏洞，同样对于关系型数据库，专门的 SQL 模糊器SQUIRREL 和 SQLANCER也没有找到漏洞。
然后对比工具的覆盖率，如图7右图，对于非关系性数据库，BuzzBee的覆盖率明显高于通用模糊测试器，而对于关系性数据库，BuzzBee的效果也能几乎达到SQL数据库专用模糊测试器的覆盖率。
3．PromptFuzz组件的有效性Bug分析
图 8 bug示例
作者在文章中列举出了BuzzBee工具在现实数据库中找到的三个漏洞。接下来看每个漏洞的具体分析。
漏洞详情：在 RedisGraph 中，执行GRAPH.QUERY g "WITH 1 AS x MATCH (m),(n) WITH * ORDER BY m SKIP 0 LIMIT 90 WHERE m = 0 RETURN 0" 查询时，服务器（v2.10.8）会触发运行时断言失败，导致崩溃。此漏洞源于处理星型投影（“WITH *” 部分）的函数。
触发条件：触发该漏洞需要满足正确的数据依赖关系。例如，若将查询中的ORDER by m 里的变量 m 更改为未定义变量（如 v0），服务器会返回 “(error) v0 not defined” 且不会崩溃。
发现过程：BuzzBee 通过其注释系统识别出定义的变量 m 和 n，并维护了正确的数据依赖关系，从而成功发现此漏洞。这体现了 BuzzBee 在处理复杂查询和确保数据依赖正确方面的能力，能够有效发现因数据依赖问题导致的漏洞。
漏洞详情：对于测试用例，HMSET k1 k1_field1 1创建了一个哈希集 k1 并存储了一个字段 / 值对，HRANDFIELD k1 -9223372036854770000 with values 命令在处理该特制命令时，HRANDFIELD 命令的处理逻辑存在整数溢出漏洞，导致redis服务器崩溃。
背景与难点：尽管该测试用例结构看似简单，但由于redis中存在大量非依赖关联操作，追溯相关代码后发现此漏洞已在代码库中隐藏至少三年，这使得发现该漏洞变得非常困难。
解决方法与发现过程：BuzzBee 利用依赖引导突变来解决此问题。当测试用例中存在 HMSET 命令时，它会主动搜索能够形成新数据依赖关系的操作。通过这种方式，BuzzBee 成功发现了这个隐藏已久的漏洞，展示了其在处理非依赖关联操作较多的数据库时，挖掘深层次漏洞的能力。
案例 C：Redis 中的断言失败漏洞（使用后失效数据依赖）
漏洞详情：测试用例首先创建一个名为set1 的哈希集并调用 EXPIRE 使其失效，接着 HINCRBYFLOAT set1 k -inf with values 命令在处理过期符号时错误地实现了错误处理程序，使数据库管理系统处于脆弱状态，最后 HRANDFIELD set1 -3 WITHVALUES 命令可导致服务器崩溃。这个漏洞我们可以看出，他先使得这个set1失效，然后又对这个set1进行了Use类的操作。这很明显是一个语义错误的操作语句，这违反了数据依赖规则。这个漏洞也就是BuzzBee！gcs找到并触发的。因为根据语义约束，其他工具不会产生这种语义错误的测试用例。
触发条件：此漏洞需要一种特殊的“失效后使用” 数据依赖关系来触发。
发现过程：为了使用BuzzBee工具复现此漏洞，研究人员手动修改了 EXPIRE 命令的注释从 “Invalidate”（失效）到 “Use”（使用）来测试数据库管理系统对无效化数据的处理情况。基于此发现，未来计划在BuzzBee 中引入新的模式，自动修改某些注释以发现类似部分违反数据依赖规则的漏洞，进一步提升其漏洞发现能力。
图9给出了BuzzBee工具找到的漏洞列表，其中包含了包括redis, KeyDB, RedisGraph, AgenmsGraph, MongoDB, ArangDB, PostgreSQL和MySQL等8个数据库的40余个漏洞。在图9中的status栏目，* 表示 BuzzBee 在最新的数据库管理系统（DBMS）中发现了该漏洞，作者报告此漏洞时供应商已经知晓。†表示该漏洞是已知的，但不在最新的 DBMS 中。
在这项工作中，作者明确了在对不同的数据库管理系统（DBMS）接口进行模糊测试时所面临的独特挑战。作者提出了相应的解决方案，并将其整合到一个开源的端到端模糊测试框架——BuzzBee 中。并且该文章对BuzzBee 进行了全面的评估，与最先进的模糊测试工具相比，BuzzBee 实现了高达177% 的代码覆盖率，并且在主流数据库管理系统中发现了40 个实际存在的漏洞，这表明了它的通用性和有效性。
mGPTFuzz：大型语言模型辅助Matter物联网设备模糊测试
Halo：通过可能不变量推断的反例引导定向模糊测试
SEAMFUZZ：灰盒模糊测试的学习种子自适应突变策略
![Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试]( "Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试")
原文始发于微信公众号（FuzzWiki）：Towards Generic DBMS Fuzzing：面向通用数据库的模糊测试
图 1 BuzzBee流程图
评论