Redis 数据库漏洞的实证研究

《Information and Software Technology》：An empirical study on bugs in redis database

　　摘要背景：数据库被广泛用作基础设施软件。一旦数据库出现缺陷，就会对企业和终端用户产生巨大影响。Redis是一种具有高度代表性、高性能的键值存储NoSQL数据库。目标：深入了解历史缺陷的特征有助于发现和修复未来的缺陷，从而提高软件质量。为了从时间、位置、症状、受影响功能、缺陷修复和根本原因等方面理解Redis数据库缺陷的特征，本文进行了一项实证研究。方法：该实证研究涉及Redis代码库中的1763份缺陷报告和1141个修订版本。分析主要涵盖五个方面：何时何地、症状、受影响功能、缺陷修复和根本原因。结果：（1）2020年后缺陷报告激增，其在2020-2021年的峰值可能与Redis 6.0的发布有关；缺陷最多的组件是服务器组件；缺陷最多的两个源文件是src/server.c和src/server.h，均与服务器组件相关。（2）缺陷最常见的症状是行为错误、崩溃和非致命错误。（3）受缺陷影响最大的三个功能是命令/Redis-cli、数据结构以及持久化（RDB、AOF）。（4）大多数缺陷可以通过少量修改代码行和少量修改文件来修复，且超过一半的缺陷在一个月内得到修复。（5）缺陷最常见的根本原因是语义缺陷，其次是内存和环境/配置；处理缺陷和缺失功能是最常见的语义缺陷。结论：这些发现可以帮助开发者提高开发质量，帮助维护者和测试者更有效、更全面地发现和修复缺陷，并为用户提供一些使用建议。引言基础设施软件，包括操作系统、数据库管理系统、中间件、办公套件和集成开发环境，构成了现代软件生态系统的基础。作为这类软件的关键类别，数据库系统在信息系统中扮演着重要角色，具体通过以下方式：（1）为应用程序运行无缝提供数据支持；（2）高效管理结构化数据以提高访问性能；（3）支持复杂查询以促进数据检索和决策；（4）支持并发多用户访问并提供安全性和隔离性；（5）提供备份和恢复机制以确保数据韧性；（6）通过数据分析工具协助战略决策。数据库系统需要高可靠性、实时性和安全性。一旦数据库发生故障，负面影响是显著的：（1）关键信息可能丢失，扰乱业务运营和决策；（2）系统或部门间的数据不一致可能降低决策准确性；（3）应用数据不可访问可能导致服务中断，损害用户体验和客户信任，并导致直接经济损失或间接客户流失；（4）可能出现安全漏洞，导致数据泄露和用户隐私风险；（5）不合规的数据管理可能违反法规，引发法律责任和罚款；（6）故障排查和恢复工作可能延误项目进度。总之，从用户角度看，数据库故障可能损害用户体验并暴露隐私数据；而从企业角度看，可能遭受广泛的运营、财务和声誉损失。因此，数据库系统必须经过充分测试以保证其质量和可靠性。人们已经研究了数据库的测试和质量保证技术。例如，Rigger和Su提出了ToREC来检测数据库引擎中的优化缺陷[1]；Tang等人开发了DLBD，一个用于检测数据库中逻辑缺陷的系统[2]；Liu等人提出了Amoeba来检测数据库系统中的性能缺陷[3]。分析历史缺陷的特征可以帮助人们更有效地发现、修复和避免未来的缺陷。然而，目前关于数据库缺陷的实证研究仍然不足。Cui等人从六个主流数据库系统中收集了140个事务缺陷[4]，Wright等人对MySQL服务器缺陷进行了实证分析，发现许多缺陷被错误分类为非缺陷[5]；两者都侧重于特定类别的缺陷。这导致对数据库缺陷特征的理解不足。缺乏关于缺陷特征的充分证据，测试资源被盲目分配，缺陷分类和修复调度不可预测，开发者和用户无法判断哪些功能最值得关注。我们希望探索数据库缺陷的特征，这可以帮助数据库开发者提高开发质量，帮助测试者和维护者更有效地检测和修复数据库系统中的缺陷，并帮助数据库用户避免潜在风险。数据库系统大致分为关系数据库管理系统（RDBMS）和不仅仅是SQL（NoSQL）数据库。NoSQL数据库比传统关系系统提供更大的数据模型灵活性，适应动态变化的数据结构。随着大数据和云计算的发展，NoSQL数据库在处理大规模数据集和支持水平扩展方面表现出色。它们通常针对特定应用场景进行优化，在高并发和低延迟下提供高效的数据访问。在NoSQL数据库中，键值存储发挥着关键作用，特别是在高性能和低延迟检索场景中。它们使用简单的键值对实现快速数据访问和大量数据的高效存储。Redis（远程字典服务器）是一个突出的内存键值数据库，为延迟敏感型应用提供超低延迟和高吞吐量。除了基本的键值存储，Redis还支持多种数据结构，包括列表、集合、有序集合和哈希。它还提供持久化机制（RDB和AOF）以确保数据持久性。凭借活跃的社区和广泛的多语言生态系统，Redis已成为Twitter、GitHub和Snapchat等主要公司技术栈的关键组成部分。Redis广泛应用于缓存、会话存储、实时分析、排行榜和消息队列，在生产环境中具有经过验证的可靠性和效率。它在新兴领域也越来越被采用，包括云原生架构、边缘计算和机器学习管道。因此，我们对Redis数据库中的历史缺陷进行了一项实证研究。在GitHub上共收集了4467个关闭的问题。经过对问题的标题、关键词、标签等因素的筛选，最终研究对象包括1763份非重复缺陷报告。此外，还收集了1141个相应的缺陷修复修订版本作为研究对象。为控制人工工作量，在涉及人工分析的子研究中随机抽取了329份缺陷报告，确保在95%置信水平下置信区间不超过5%。通过人工分析和定量分析探索Redis缺陷的特征，以回答以下研究问题：•RQ1（何时何地）：缺陷是什么时候发现的？缺陷随时间如何分布？缺陷出现在哪里？哪些组件和源文件是缺陷的主要来源？•RQ2（症状）：缺陷可能有哪些症状？这些症状如何分布？•RQ3（受影响功能）：受缺陷影响的功能有哪些？这些受影响功能如何分布？•RQ4（缺陷修复）：修复缺陷需要多少工作量？修复缺陷需要多长时间？•RQ5（根本原因）：缺陷的根本原因是什么？根本原因如何分布？这些研究问题的答案可以总结如下：•何时何地：2020年后报告了许多缺陷，其峰值可能与Redis 6.0的发布有关。缺陷最多的组件是服务器组件，其次是数据结构和网络组件。缺陷最多的两个源文件是src/server.c和src/server.h，均与服务器组件相关，其次是src/module.c和src/networking.c。上述每个源文件中都有超过100个缺陷。•症状：最常见的缺陷症状是行为错误和崩溃，分别占40.73%和27.05%。非致命错误也占很高比例，占20.36%。•受影响功能：受缺陷影响最大的三个功能是命令/Redis-cli、数据结构和持久化（RDB、AOF），需要特别关注。缺陷对其他功能的影响较小，所有其他功能受缺陷影响的比例均低于10%。具体而言，哨兵、Redis缓存、发布/订阅、访问控制列表和活动碎片整理受缺陷影响的比例低于5%。•缺陷修复：大多数缺陷需要较少工作量即可修复。超过80%的缺陷在100行代码修改内修复，在10行代码修改内修复的缺陷比例接近40%。同样，54.95%的缺陷通过修改一个文件修复。缺陷修复所需时间严重两极分化。53.73%的缺陷在一个月内修复，需要一年以上修复的缺陷占21.21%。•根本原因：最常见的根本原因是语义缺陷，占56.53%，其次是内存和环境/配置，分别占10.64%和10.33%。此外，处理缺陷和缺失功能是最常见的语义缺陷，分别占18.54%和11.25%。上述发现可以帮助Redis数据库开发者、测试者和维护者理解历史缺陷的特征和模式，从而提醒他们应该关注什么，帮助他们更有效、更高效地检测和修复缺陷，最大限度地减少重复缺陷，降低质量风险，提高开发质量。此外，Redis用户也可以从上述发现中受益：他们应该避免高风险的功能和组件。本文的主要贡献包括：•首次收集和整理Redis数据库中的缺陷报告，并对Redis数据库中的缺陷进行实证研究。•调查了缺陷出现的时间和位置，并分析了受缺陷影响的功能分布。结果可能帮助Redis用户规避风险，并建议Redis开发者和测试者更多关注高风险位置。•探索了修复缺陷所需的工作量和时间。结果可能帮助Redis维护者更有效、更高效地修复缺陷。•分析了缺陷症状和根本原因的分布。结果可能帮助Redis维护者更有效地理解缺陷，并协助Redis开发者避免缺陷。论文组织：第2节介绍实证研究方法。第3节调查缺陷随时间和位置的分布。第4节分析缺陷症状。第5节分析受缺陷影响的功能。第6节探讨缺陷修复的特征。第7节分析缺陷的根本原因。第8节给出启示。第9节讨论有效性的潜在威胁。第10节回顾相关工作。第11节给出结论。章节片段实证研究方法实证软件工程是软件工程领域一个流行的研究方向。对软件缺陷的实证研究已形成一种经典方法论，被广泛用于理解各类软件中缺陷的特征，如编程语言[6]，[7]、编译器[8]、深度学习框架[9]和开源应用系统[10]，[11]，[12]。我们的研究问题旨在描述缺陷何时、何地以及如何显现和分布。缺陷随时间的分布图1显示了Redis缺陷报告随时间的分布。橙色区域代表每月新开的缺陷报告数量，蓝色区域代表每月关闭的缺陷报告数量。横轴标记缺陷报告打开或关闭的年份，纵轴代表每月打开或关闭的缺陷报告总数。从图1可以看出，2020年后，每月打开和关闭的缺陷数量显著增加，且缺陷症状我们参考Yang等人[13]、Liu等人[14]和Zhang等人[15]使用的缺陷症状分类标准来确定缺陷症状类别。选择了六种符合Redis特征的症状，包括行为错误、崩溃、非致命错误、资源使用、低效率和无响应。这些症状的描述可在https://github.com/rressett/EmpiricalStudy-Redis/blob/main/symptom-description查看。根据研究设计，受影响功能我们根据官方网站上的文档确定Redis提供的功能类别。89它们包括安全、哨兵、复制、集群、持久化（RDB、AOF）、数据结构、网络、Lua脚本、发布/订阅、Redis-cli、模块、缓存和命令。在分析过程中持续迭代，我们分析和分类功能修改的代码行修改的代码行数（LOC）被视为评估软件产品规模的指标之一[18]，被认为与开发工作量高度相关。因此，修改的代码行数可以作为估算缺陷修复所消耗工作量的合理指标。

修改的代码行数越多，通常意味着修复漏洞的过程变得更加复杂和困难。表5展示了修复漏洞所涉及修改代码行数的分布及总体统计。漏洞的根本原因我们识别了漏洞根本原因的类别。我们参考了Tan等人[17]和Wang等人[7]所采用的漏洞根本原因分类标准。基于他们分类漏洞根本原因的经验并使用多种迭代分析方法，我们最终确定Redis漏洞的根本原因分为八大类别（包括内存、并发、语义、性能、平台、环境与配置、构建、版本）。启示对Redis开发者的启示：•关于漏洞位置的实证结果表明，开发者应优先优化服务器和网络组件，以提升代码质量和稳定性。服务器组件是最易出错的部分，负责命令解析、内存管理和事件循环。对该组件的修改需要谨慎，以防止命令处理错误、内存泄漏或无限循环等问题。网络组件是第二易出错的组件。效度威胁我们的实证研究可能受到以下方面的威胁。研究对象的代表性：Redis是数据库系统中具有高度代表性的开源高性能键值存储NoSQL数据库。本文对Redis漏洞的研究对基于内存存储的数据库具有一定的通用性，这类数据库读写速度极快，适用于需要快速响应和高并发的场景，以及支持多种数据结构的数据库。相关工作数据库漏洞的特征分析与检测及其可靠性评估：为了解数据库中漏洞的特征，Cui等人从六个主流数据库系统中收集了140个事务性漏洞。他们针对漏洞的表现形式、根本原因、影响、修复方式以及现有方法的检测能力进行了实证研究。结果显示，事务性漏洞具有小规模触发、静默失败发生率高以及检测不充分等特征。结论我们对Redis数据库中的漏洞进行了实证研究，主要分析了1763份非重复漏洞报告及与漏洞对应的1141次修订。我们分析了漏洞的总体分布、症状、受影响特性、修复方式及根本原因。研究结果如下：（1）2020年后漏洞报告激增，其高峰出现在2020至2021年，可能与Redis 6.0的发布有关；漏洞最多的组件是服务器组件；漏洞最多的两个源文件是。作者贡献声明Ziyuan Wang：撰写—审阅与编辑、验证、监督、方法论、调查研究。Wentian Xie：撰写—初稿、调查研究、数据整理。Sufan Zhang：撰写—审阅与编辑、数据整理。Yun Fang：撰写—审阅与编辑、调查研究。利益冲突声明作者声明不存在任何可能影响本文所述工作的已知竞争经济利益或个人关系。Ziyuan Wang | Wentian Xie | Sufan Zhang | Yun Fang 南京邮电大学计算机科学与技术学院，中国南京。