WINGFUZZ: Implementing Continuous Fuzzing for DBMSs

Abstract

数据库管理系统（DBMS）是软件生态系统中的关键组件，其安全性和稳定性至关重要。近年来，模糊测试已成为一种重要的自动化测试技术，有效地识别了各种DBMS中的漏洞。然而，许多模糊测试工具需要针对特定版本的DBMS进行特殊适配。在企业级DBMS上持续进行测试面临挑战，因为这些DBMS具有多样化的规格且版本更新迅速。

在本文中，我们介绍了在企业级DBMS（如ClickHouse）上实施持续模糊测试的行业实践。我们总结了实现这一过程中的三个主要障碍，分别是测试用例生成中的多样化SQL语法、持续测试中代码库的不断演化以及异常分析期间的噪声干扰。我们提出了WINGFUZZ，通过使用基于规范的变异生成、基于语料库的代码演化模糊测试以及抗噪异常评估来解决这些问题。通过与工程师合作进行持续DBMS模糊测试，我们在12种广泛使用的企业级DBMS（包括ClickHouse、DamengDB和TenDB）中发现了总计236个之前未发现的漏洞。由于其显著的测试效果，我们的努力得到了部分DBMS厂商的认可和合作邀请。例如，ClickHouse的CTO称赞道：“你们使用了什么工具找到这个测试用例？我们需要将其集成到我们的CI中。” WINGFUZZ已经成功集成到其开发过程中。

Introduction

背景

现代软件应用程序在很大程度上依赖数据库管理系统（DBMS）来高效地存储和管理数据。由于DBMS的复杂性和版本的快速迭代，错误在所难免。一旦这些错误被攻击者利用，可能会导致信息泄漏、系统崩溃以及上层应用程序运行中断等一系列问题。因此，DBMS的弹性和安全性已成为组织和企业的首要考虑因素。

业界和学术界已经开发了许多方法来检测DBMS中的问题，其中模糊测试是一种有效的评估DBMS安全性的方法，揭示了许多漏洞。模糊测试的基本过程是生成一系列格式错误的输入并监控异常行为。为了测试DBMS，模糊测试工具通常为每个DBMS建模特定的SQL规范，以生成在语法和语义上都正确的结构化SQL输入。例如，SQLsmith通过将PostgreSQL的语法建模为抽象语法树（AST）来生成查询，自2015年至2023年间在PostgreSQL中发现了大约80个错误。

现有Fuzzing工具的局限性：

三个障碍总结：

  1. 多样化的SQL语法：由于不同DBMS的语法规则各不相同，生成测试用例变得困难。例如，PostgreSQL和MySQL的字符串连接语法不同，前者使用’||’操作符，而后者需要CONCAT()函数。因此，为了全面测试DBMS，许多模糊测试工具必须手动定制以适应独特的语法。自动适应不同DBMS和快速演变的DBMS版本的解决方案对于企业级DBMS至关重要。 （写作参考）
  2. 代码库的持续演变：企业级DBMS为了满足用户不断变化的需求和应对新兴的安全挑战，频繁更新以提升性能、修复漏洞和引入新功能。这使得持续测试变得困难。例如，ClickHouse使用持续集成系统自动验证和合并新的提交。模糊测试工具必须跟上这些变化，但高效测试新版本中的更新部分仍然具有挑战性。 （写作参考）
  3. 噪声干扰：自动恢复机制和测试的连续执行引入了噪声，增加了异常检测和分析的复杂性。自动恢复机制在异常发生时控制错误线程恢复正常状态和数据，这可能导致连接不被中断，从而错过异常。此外，连续执行测试的模糊测试工具会因前序测试用例对系统状态的更改而产生干扰。

key insight：

本文提出并分析了在企业级DBMS上实施持续模糊测试的三个主要障碍，并提出了WINGFUZZ来解决这些问题。WINGFUZZ通过以下方式实现对DBMS的持续模糊测试：

  1. 基于规范的变异生成：框架根据DBMS的语法规范自动生成独特的查询解析器，解决了多样化SQL语法的问题。
  2. 基于语料库的代码演化模糊测试：框架通过生成的测试用例进行长期模糊测试，优先覆盖更新的提交部分，从而应对代码库的持续演变。
  3. 抗噪异常评估：框架监控每个线程并隔离异常线程，以捕捉异常及其详细数据。识别出的异常经过去重后报告给开发人员以便及时解决。

通过这种方法，WINGFUZZ能够高效地进行持续模糊测试，发现并报告DBMS中的漏洞和异常。

Evaluate and contributions：

通过与工程师合作进行模糊测试，我们在包括ClickHouse、DamengDB、PolarDB和TenDB在内的12个DBMS中发现了总计236个之前未发现的漏洞，其中232个已被确认。我们的工作得到了这些DBMS厂商的认可。例如，ClickHouse的CTO称赞我们的工具，并将WINGFUZZ成功集成到其开发过程中。MonetDB的开发者称赞我们的漏洞报告是他们所期望的最佳类型，SQLite的创始人称WINGFUZZ是“突破性的分析工具”。

我们的贡献包括：

  1. 总结了在实现持续DBMS模糊测试中面临的三大障碍：多样化的SQL语法、代码库的持续演变和噪声干扰。
  2. 提出了一个名为WINGFUZZ的持续DBMS模糊测试框架，提供了相应的解决方案，包括基于规范的变异生成、基于语料库的代码演化模糊测试和抗噪异常评估。
  3. 我们将WINGFUZZ部署到12个企业级DBMS中，持续进行模糊测试，发现了236个之前未知的漏洞，提高了这些DBMS的安全性，并获得了相关厂商的认可。

Background

DBMS和SQL：数据库管理系统（DBMS）是一种允许用户创建、存储、检索和管理数据的软件应用程序。DBMS使用结构化查询语言（SQL）来定义、操作和查询数据库的数据。SQL输入必须严格遵守语法和语义的正确性，任何偏离指定格式和正确性的输入都会被拒绝。

持续集成系统（CI）：持续集成是一种软件开发实践，涉及将每次代码更改集成到共享代码库中，并在提交之前自动对每次修改进行测试。这一实践确保新代码不仅能顺利与现有代码库集成，还能在不引入错误的情况下完成。

DBMS恢复机制：DBMS可能会因软件问题或硬件故障而发生故障。在生产环境中，即使面临故障，DBMS保持运行是至关重要的。DBMS恢复技术在系统故障后恢复数据以及确保数据库的原子性和持久性方面起着重要作用。

Obstacles in Continuous DBMS Fuzzing

image-20240708105330798

3.1 Step 1: Customize Query Generator

第一步是为特定的DBMS定制查询生成器。查询生成在DBMS模糊测试中起核心作用，因为它决定了可以覆盖的功能和特性。DBMS通常具有许多特性，要全面测试DBMS，生成的SQL查询需要覆盖这些特性，因为许多潜在的错误可能存在于相关代码中。此外，确保生成的查询在语法和语义上的正确性也很重要，任何有问题的输入都会被拒绝，从而阻止深入逻辑的探索。

障碍1：多样化的SQL语法：不同的DBMS具有独特的语法、语义和优化策略。多样化的SQL语法给SQL测试用例的生成带来了困难。针对每个DBMS的具体情况定制生成器可以确保生成的查询与目标系统兼容，从而提高测试过程的有效性。这种定制对于生成不仅语法正确且符合目标数据库系统独特语言细微差别的查询，以覆盖深层逻辑至关重要。例如，在图2中，列定义中使用的数据类型是每个数据库系统特有的（如PostgreSQL中的VARCHAR与ClickHouse中的String）。此外，ClickHouse使用ENGINE子句定义存储引擎，而PostgreSQL没有类似的语法。

image-20240708105407795

3.2 Step 2: Fuzz Evolving Codebase

第二步是对不断演变的代码进行持续模糊测试。企业级DBMS的代码不断演变以满足不断变化的业务需求、利用技术进步、解决安全问题、提高可用性和满足不断变化的合规要求。为了确保稳定性、安全性和效率，提交的代码更改通常会经过严格的测试和验证。

障碍2：代码库的持续演变：代码库的持续演变为持续模糊测试带来了困难。要对不断变化的代码进行模糊测试，必须在代码提交时迅速进行，同时保持彻底测试整个代码库的能力。高效测试新版本中更新部分是一个挑战。首先，在应用于特定代码提交时，挑战在于在更广泛的应用程序上下文中隔离和评估该提交的安全影响。理解新代码影响的确切触发器、输入和数据路径尤其复杂，特别是在具有众多依赖关系的复杂软件生态系统中。

此外，软件开发中的速度需求增加了这一障碍的复杂性。实际上，企业级DBMS总是采用CI系统来集成代码提交。它需要快速的安全验证以确保代码提交不会引入漏洞。然而，传统模糊测试的全面性可能会阻碍开发团队的敏捷性。进行彻底的模糊测试可能会耗费大量时间，因为它通常需要大量执行时间来探索广泛的潜在输入。

3.3 Step 3: Detect and Analyze Anomalies

最后一步涉及对中断事件的错误检测和分析，包括异常识别、异常去重和最小化。在查询执行过程中可能会发生异常。为了检测这些异常，模糊测试工具需要主动监控系统，识别任何偏离预期或期望行为的情况。随后，需要将异常去重为唯一的异常。为了查明异常的根本原因，会保存并分析触发异常的输入以及异常的现场信息（如数据、元数据、堆栈跟踪）。

障碍3：噪声干扰：异常事件中的噪声会影响异常检测和分析。检测中的噪声主要来自内置的异常恢复机制。模糊测试工具通常通过评估与DBMS的连接可用性来确定异常，但恢复机制会确保DBMS保持连接。例如，ClickHouse在崩溃后进行的复杂程序（包括查询日志记录、转储生成和错误检查）会导致迅速获取关键崩溃现场信息的延迟。这些过程虽然对于系统恢复和确保数据完整性至关重要，但会阻碍迅速识别和解决异常。在此过程中，ClickHouse与模糊测试工具保持连接，甚至可以继续接受生成的查询。因此，模糊测试工具在确定DBMS是否崩溃时会遇到挑战。

其次，恢复机制也会为异常分析带来噪声。具体而言，该机制可能会中断有问题的线程，将异常的调用堆栈与多个线程的调用堆栈混合。这会为用于异常分析的堆栈跟踪引入噪声。此外，先前查询执行中的噪声也会影响分析。许多最先进的模糊测试工具在DBMS上连续执行测试，导致测试之间的干扰。一旦触发异常，可能不仅由当前测试用例引起，还与先前测试用例的状态变化有关。

Solutions of WINGFUZZ

image-20240708110621923

WINGFUZZ概述：

  1. 步骤1：克服多样化的SQL语法：WINGFUZZ从DBMS的语法规范构建查询变异器，以适应不同的SQL语法。
  2. 步骤2：应对代码库的持续演变：WINGFUZZ持续模糊测试最新版本，积累语料库以快速进行受版本更改影响的代码提交模糊测试。
  3. 步骤3：隔离噪声：WINGFUZZ隔离测试用例的执行，直接捕捉异常信号，从而避免噪声干扰。

图3展示了WINGFUZZ的整体概览。

4.1 Specification-Based Mutator Construction

WINGFUZZ通过从DBMS语法规范中自动派生定制变异器来解决障碍1。它通过变异现有查询来生成新查询，同时保留语法结构。SQL变异器由两个组件组成：SQL转换器和AST变异器。SQL转换器将SQL查询转换为AST，然后AST变异器修改原始AST的结构或数据元素（例如，在SELECT语句后添加“ORDER BY”或用SELECT子句替换表）以生成新的AST。然后，通过分析对象和流行数据之间的依赖关系，将新的AST转换为SQL查询。SQL变异器通过中间语法规则识别查询的结构和数据，这些规则由统一范式表示。

统一语法范式：该范式是带有语义信息的BNF范式的扩展。它遵循上下文无关语法，结合描述DBMS SQL数据模型的数据元素。数据元素用区分类别的符号标记（例如，表和列）。图4展示了使用该范式描述altertablestmt递归归约规则的示例。具体来说，altertablestmt是一个非终结符号，后跟相应的归约规则。在最后一行，name（代表TABLESPACE名称）标记为@DataT Name。利用统一语法范式，可以统一各种语法规则，从而构建定制的SQL变异器。

定制变异器构建：算法1展示了根据SQL语法规范自动构建SQL变异器的过程。首先，它从SQL语法文件中提取标记和SQL语法规则（例如，关键字和特定规则），然后使用统一语法范式将它们转换为中间语法规则（步骤1-3）。接着，对于中间语法规则中的每个语法规则，分析规则以找到表示DBMS数据模型的数据相关元素（例如，表、列和模式）。将为每个数据元素添加特定的变异规则（例如，一个表对象只能填充表名），这些规则用于变异AST的数据元素（步骤5-7）。最后，这些标记和规则将用于生成SQL转换器的词法分析器（步骤9-10），统一语法范式G’将用于生成AST变异器（步骤11）。

**统一语法范式 (Uniform Grammar Paradigm)**：

  1. 定义：这是BNF（巴科斯-诺尔范式）语法的扩展，包含语义信息。它使用上下文无关语法，结合描述DBMS SQL数据模型的数据元素。
  2. 数据元素标记：在这个范式中，数据元素被用符号标记以区分类别。例如，表和列被标记为不同的符号，以便于识别和处理。
  3. 例子解析：
    • altertablestmt 是一个非终结符号，它代表一个“ALTER TABLE”语句。
    • 这个符号后面跟着其相应的归约规则，这些规则定义了如何将altertablestmt扩展成更具体的语法结构。
    • 例如，规则中包含多个“ALTER TABLE”语句的不同变体：
      • ALTER TABLE relation_expr alter_table_cmds
      • ALTER TABLE IF_P EXISTS relation_expr alter_table_cmds
      • ALTER TABLE relation_expr partition_cmd
      • ALTER TABLE IF_P EXISTS relation_expr partition_cmd
      • ALTER TABLE ALL IN_P TABLESPACE name
    • 在这些规则中，relation_expr、alter_table_cmds、partition_cmd等都是其他非终结符号，进一步定义了这些语句的细节。
  4. 语义标记：
    • 在最后一行中，name 被标记为 @DataTName，表示这是一个数据元素，具体来说是TABLESPACE的名称。这种标记提供了关于这个符号的额外语义信息，有助于SQL查询生成器理解和生成正确的查询结构。

在BNF中，这个语句可以表示为：

1
2
3
4
5
<alter_table_stmt> ::= "ALTER TABLE" <table_name> <alter_cmd>
<alter_cmd> ::= "ADD" <column_name> <data_type>
<table_name> ::= "table_name"
<column_name> ::= "column_name"
<data_type> ::= "VARCHAR(255)"

在统一语法范式中，我们添加语义信息来描述SQL数据模型：

1
2
3
4
5
<alter_table_stmt> ::= "ALTER TABLE" <table_name> <alter_cmd>
<alter_cmd> ::= "ADD" <column_name> <data_type>
<table_name> ::= @DataTName "table_name"
<column_name> ::= @DataCName "column_name"
<data_type> ::= "VARCHAR(255)"

在这个例子中，@DataTName 表示 table_name 是一个表的名称，@DataCName 表示 column_name 是一个列的名称。

通过添加这些语义信息，统一语法范式不仅描述了SQL语句的语法结构，还提供了关于数据模型的额外信息。这使得SQL变异器能够在生成新的查询时，更好地理解和利用这些信息，从而生成符合目标DBMS特定要求的正确SQL查询。

例如，在生成新的ALTER TABLE语句时，变异器可以确保只使用有效的表名和列名，并正确应用数据类型。这有助于提高模糊测试的有效性和覆盖率，确保测试用例不仅语法正确，而且在语义上也与目标DBMS兼容。

统一底层语法格式来添加更多的DBMS feature，例如表名、列名等等

4.2 Corpus-Driven Evolving Code Fuzzing

WINGFUZZ通过使用长期模糊测试生成的语料库进行快速提交模糊测试来克服障碍2。其基本过程包括：

  1. 长期模糊测试：WINGFUZZ维护一个包含最小输入的语料库，这些输入能够提供最广泛的代码覆盖率。
  2. 提交模糊测试：当代码库有新的提交时，WINGFUZZ从现有语料库中提取与提交相关的特定输入，进行限时模糊测试，重点覆盖新提交代码的相关部分。
  3. 持续模糊测试：测试完成后，重新启动长期模糊测试以测试最新代码更改。以前覆盖的代码仍然可以通过现有种子进行测试。

提交模糊测试：其目的是快速确定提交的代码中是否存在潜在问题或漏洞。传统模糊测试通常测试整个系统，效率低下。WINGFUZZ通过以下算法提高效率：

  1. 使用静态分析获取与提交相关的函数。
  2. 过滤语料库中的测试用例，找到覆盖相关函数的测试用例。
  3. 使用过滤后的语料库进行模糊测试，专门跟踪提交更改的覆盖情况。
  4. 在模糊测试过程中选择测试用例、进行变异并更新语料库。测试用例既覆盖提交代码又有新覆盖的，将被添加到语料库中。

CI集成：商用DBMS通常使用CI系统合并代码提交。基于语料库的演变模糊测试可以无缝集成到CI系统中，步骤包括：

  1. 将提交模糊测试作为集成测试中的一个检查步骤。发现异常则标记为检查失败，保存异常详情并阻止代码合并。
  2. 在专用服务器上持续进行长期模糊测试。当提交通过所有CI检查后，长期模糊测试重新开始测试更新的代码。如果发现问题或漏洞，触发自动报告机制，测试继续进行，触发异常的输入将被添加到回归测试集中。
image-20240708113320620

4.3 Noise-Resilient Anomaly Assessment

WINGFUZZ通过直接跟踪每个DBMS线程并在执行每个测试用例前删除数据库来解决障碍3。为了避免在触发异常时系统噪声的干扰，WINGFUZZ直接跟踪每个线程并暂停整个系统。

过程概述：

  1. 实时监控：WINGFUZZ实时监控每个线程以检测异常。一旦从任何线程接收到异常信号，就将其分类为DBMS异常。
  2. 拦截和分析：监控器拦截信号并暂停线程。随后，错误分析器提取线程的堆栈跟踪以及其他综合数据（如覆盖共享位图和相关系统变量）。这些详细信息为后续分析和调试提供了宝贵资源。
  3. 系统终止和重启：错误分析器终止整个DBMS，绕过其恢复机制（包括内置的错误日志记录、检查等功能）。然后，WINGFUZZ删除所有数据库并重启DBMS，为后续测试提供干净环境。
  4. 异常分析：详细的异常信息可以在线或离线分析。利用堆栈跟踪和其他信息进行异常去重，并生成简明报告，阐明潜在的根本原因和受影响的组件。

消除噪声策略：

为了避免来自之前执行的噪声，WINGFUZZ采用隔离单个测试用例执行的策略。在启动每个测试用例执行之前，系统会系统地删除所有数据库。此方法消除了先前测试的残留数据和副作用，为当前测试用例提供了干净的状态。一旦测试用例触发异常，便于使用当前测试用例进行错误重现和分析。

image-20240708113714050

Implementation

基于上述解决方案，我们实现了一个名为WINGFUZZ的持续DBMS模糊测试框架，主要包括三个部分：查询变异器构建器、代码演变模糊测试器和抗噪错误分析器。

  1. 查询变异器构建器：
    • 基于bison和flex。
    • 大多数DBMS在其源代码中都有类似bison文件的语法描述文件，这些文件描述了标记和语法规则。例如，PostgreSQL的语法文件可以在其GitHub上下载。
    • 对于缺乏此文件的DBMS，可以从官方文档中提取语法描述。
    • 统一语法范式遵循带有一些SQL数据元素的BNF格式。
    • 变异器构建器首先将标记和语法规则转换为bison和flex格式的统一范式，使用2034行Python代码。
    • 然后使用bison和flex生成SQL转换器和AST变异器。
  2. 模糊测试模块：
    • 包括进行模糊测试的基本组件，如包装编译器（封装不同参数用于覆盖率检测）、测试用例选择器、语料库更新器和基于语法规范构建的变异器。
    • 支持CI集成，通过脚本实现。
  3. 抗噪错误分析器：
    • 监控每个线程的异常信号以捕捉异常。
    • 异常信号是操作系统信号，指示需要立即处理的各种错误，如SIGSEGV、SIGILL、SIGBUS、SIGABRT和SIGFPE。
    • 这些信号可能发生在DBMS的任何子进程或子线程中。
    • 通过fork()和exec()将DBMS作为监控器的子进程启动，使用ptrace监控DBMS进程。
    • 监控器跟踪DBMS进程接收到的所有信号，如果信号是异常信号，意味着潜在的错误被触发，调用libunwind-ptrace的API从进程中检索调用堆栈。
    • 监控器还跟踪进程的clone()、fork()、vfork()和exec()调用，以全面监控所有子进程和线程。

该框架通过这些实现，确保了对DBMS的高效、全面的模糊测试，同时能够迅速检测和分析异常，提供可靠的错误报告和调试信息。

Evaluation

6.1 Compared with Existing Fuzzers

为了展示WINGFUZZ的有效性，我们将其与三种最先进的模糊测试工具进行了比较：SQLancer、SQLsmith和SQUIRREL，这些工具在业界和学术研究中广泛使用。

测试DBMS和度量标准：

  • 我们选择了四个开源DBMS作为测试目标：PostgreSQL、MySQL、MariaDB和PolarDB。
  • 这些DBMS在工业界和学术研究中被广泛使用。
  • 测试使用了最新版本的DBMS，并比较了每个工具在24小时内发现的分支覆盖数和触发的唯一错误数。

主要发现：

  1. 分支覆盖：
    • WINGFUZZ在24小时内覆盖了211,620个分支，比其他工具覆盖的分支更多。
    • 具体数据见表1，WINGFUZZ覆盖的分支数显著超过SQLancer、SQLsmith和SQUIRREL。
    • image-20240708114243075
  2. 唯一错误：
    • WINGFUZZ在24小时内触发了27个唯一错误，同样多于其他工具。
    • 具体数据见表2，WINGFUZZ在PostgreSQL、MySQL、MariaDB和PolarDB上均发现了更多的唯一错误。
    • image-20240708114317712

结论：

  • WINGFUZZ的增强覆盖率主要来自两方面的因素：
    1. 覆盖率的提高意味着WINGFUZZ能够涵盖目标DBMS中的独特功能，从而发现潜在的错误。
    2. WINGFUZZ利用了抗噪异常评估，直接监控DBMS每个线程的异常信号。
  • 在错误重现过程中，WINGFUZZ通过在每次测试用例执行前重置数据库，确保大多数异常能够被重现。

这些结果表明，WINGFUZZ在发现和触发DBMS中的唯一错误方面表现优异，展示了其作为持续模糊测试工具的有效性和优势。

6.2 Contributions of Each Component

为了评估WINGFUZZ每个组件的有效性，我们实现了不同版本的WINGFUZZ：WingFuzzraw_{raw}raw、WingFuzzg_{g}g 和 WingFuzzg+e_{g+e}g+e。

  • WingFuzzraw_{raw}raw：使用AFL中的原始变异算法，不进行语法适配。
  • WingFuzzg_{g}g：启用了基于语法的变异构造。
  • WingFuzzg+e_{g+e}g+e：在WingFuzzg_{g}g的基础上，还启用了代码演变模糊测试。

为公平比较，我们首先运行30分钟的提交模糊测试，然后启用常规模糊测试。WingFuzzall_{all}all（即WINGFUZZ）启用了所有三个组件。

表3和表4展示了各版本在24小时内覆盖的分支数和发现的错误数：

  • WingFuzzraw_{raw}raw：覆盖了40147个新分支，发现了5个错误。
  • WingFuzzg_{g}g：通过改进语法和语义正确性，覆盖了更多的代码区域。
  • WingFuzzg+e_{g+e}g+e：通过有效引导模糊测试覆盖更新的代码区域，显著提高了分支覆盖率和错误发现数。
  • WingFuzzall_{all}all：尽管由于额外开销覆盖的分支较少，但发现的错误更多。
  • image-20240708114742691
  • image-20240708114756014

主要发现：

  • 语法适配提高了代码覆盖率和语义正确性，增加了错误检测的广度。
  • 代码演变模糊测试通过快速有效地测试代码更改，提高了分支覆盖率和错误检测效率。
  • 抗噪异常评估确保了大多数检测到的异常能够重现，从而提高了错误检测的准确性和可靠性。

这些结果展示了每个组件对WINGFUZZ整体性能的贡献，证明了其作为持续DBMS模糊测试工具的有效性和优势。

6.3 Practice of Deploying WINGFUZZ

6.3.1 Process of Deployment

部署过程遵循第3节概述的步骤，包括三个关键步骤：查询生成器定制、代码库演变模糊测试和异常检测与分析。以下以ClickHouse为例说明部署过程。

步骤1：定制查询生成器

  • ClickHouse使用列式存储，与传统的行式数据库不同，其SQL语法也有显著差异。
  • 在ClickHouse的源代码中，有一个bison格式的语法文件。
  • WINGFUZZ利用这个语法文件提取标记和上下文无关的语法规则。
  • 标记被整合到sqllex.l文件中生成词法分析器，语法规则被重新组织到parser-mutate.y文件中生成语法解析器和AST变异器。
  • 最终生成的词法分析器、语法解析器和AST变异器共同完成SQL变异。

步骤2：代码库演变模糊测试

  • 在专用服务器上对ClickHouse的最新版本进行了长期测试，通过WINGFUZZ提供的脚本不断监控ClickHouse的最新提交。
  • 在此过程中，发现了10个错误，引起了ClickHouse开发者的注意，并得到迅速解决。
  • 应ClickHouse的邀请，我们与他们的工程师合作，将WINGFUZZ集成到他们的开发过程中。
  • 持续进行独立测试，截至论文撰写时，我们在ClickHouse中共发现了31个错误，其中三分之二是在集成后发现的，展示了基于语料库的代码演变模糊测试的有效性。
  • 除了ClickHouse，我们还与DamengDB、YashanDB和TenDB的工程师合作部署WINGFUZZ。

步骤3：检测和分析异常

  • ClickHouse具有强大的错误恢复机制，当系统异常发生时，记录错误信息、生成核心转储文件、检查错误、执行数据恢复并重新启动DBMS。
  • 尽管这种机制保证了系统的顺利运行，但引入的噪声影响了模糊测试工具捕捉和分析异常的能力，并且增加了时间成本。
  • WINGFUZZ直接监控每个线程，当触发异常时，接管系统并提取异常信息（如调用堆栈）。
  • 随后终止所有线程，清理数据库并重启ClickHouse。
  • 在异常分析阶段，基于覆盖率和调用堆栈对异常进行去重，最终通过结合堆栈信息和触发异常的输入完成异常报告。

这个过程展示了WINGFUZZ在ClickHouse中的成功部署，以及在其他DBMS中的潜在应用。

6.3.2 DBMS Vulnerability Results

表5显示，我们使用WINGFUZZ测试了12个DBMS（如ClickHouse、DamengDB和MariaDB），共报告了236个漏洞。这些漏洞已全部报告给相应的DBMS厂商，并获得了积极回应，其中232个漏洞已被确认。

漏洞类型：

  • 约五分之四的漏洞涉及缓冲区溢出、段错误和使用后释放漏洞。这些漏洞可能被攻击者利用来执行任意代码，以控制系统或获取特殊权限，可能造成重大损害。
  • WINGFUZZ还发现了空指针解引用、未定义行为和断言失败等漏洞，这些漏洞同样对需要持续运行的数据库服务造成重大影响。
image-20240708134112915

6.3.3 Case Studies

image-20240708134442017 image-20240708134501574 image-20240708134520091 image-20240708134536716