《基于mozilla的安全性漏洞再修复经验研究》由会员分享，可在线阅读，更多相关《基于mozilla的安全性漏洞再修复经验研究（18页珍藏版）》请在金锄头文库上搜索。
1、基于 Mozilla 的安全性漏洞再修复经验研究 张凯 孙小兵 彭鑫 赵文耘 复旦大学软件学院 复旦大学上海市数据科学重点实验室 摘 要： 相较于其他类型的漏洞, 安全性漏洞更容易发生再修复, 这使得安全性漏洞需要更多的开发资源, 从而增加了这些安全性漏洞修复的成本。因此, 减少安全性漏洞再修复的发生的重要性不言而喻。对安全性漏洞再修复的经验研究有助于减少再修复的发生。首先, 通过对 Mozilla 工程中一些发生再修复的安全性漏洞的安全性漏洞类型、发生再修复的原因、再修复的次数、修改的提交数、修改的文件数、修改的代码行数的增减、初始修复和再修复的对比等数据进行分析, 发现了安全性漏洞发生再修
2、复是普遍存在的, 且与漏洞发生原因的识别的复杂程度和漏洞修复的复杂程度这两个因素有关;其次, 初始修复涉及的文件、代码的集中程度是影响再修复的原因之一, 而使用更复杂、更有效的修复过程可有效避免再修复的发生;最后, 总结了几种安全性漏洞发生再修复的原因, 使开发人员有效地识别不同类型的安全性漏洞再修复。关键词： 安全性漏洞; 再修复; 漏洞修复; 经验研究; 作者简介：张凯 (1993-) , 男, 硕士生, 主要研究方向为软件维护;作者简介：孙小兵 (1985-) , 男, 博士, 主要研究方向为软件分析、维护与演化;作者简介：彭鑫 (1979-) , 男, 博士, 教授, CCF 高级会员
3、, 主要研究方向为需求工程、自适应软件、软件产品线、软件维护、逆向工程;E-mail:;作者简介：赵文耘 (1964-) , 男, 硕士, 教授, CCF 高级会员, 主要研究方向为软件复用、软件产品线、软件工程。收稿日期：2016-10-07基金：国家自然科学基金 (61402396, 61370079) Empirical Study of Reopened Security Bugs on MozillaZHANG Kai SUN Xiao-bing PENG Xin ZHAO Wen-yun Abstract： Compared to other types of bugs, secu
4、rity bug reopens more often, moreover, they need more development resources to fix it, which adds an extra cost to fix them.Hence, the empirical study of reopened security bugs is important.Our study collected the reopened security bugs from the Mozilla project, and analyzed them from the times of t
5、heir reopening and commits, files which were modified to fix them, lines of added and deleted code, and comparison of the original fixing and reopened fixing.The empirical results show that security bug reopening often happen and it relates to the complexity of recognizing the reason that a security
6、 bug happens and fixing bugs.In addition, the locality of the files and code in the original security bug fixing is one of the causes to influence its re-fixing for bug reopens, and using more complex and effective fixing process can help reduce the security bug reopens.Finally, we summarized severa
7、l causes for security bug reopens to help developers more easily identify the reopens of different types of security bugs.Keyword： Security bug; Reopens; Bug fixing; Empirical study; Received： 2016-10-071 引言在软件开发和维护过程中, 开发人员常常遇到程序运行状态与预期不符的情况, 如输出值不正确、程序死机、数据丢失等, 这种现象来源于程序的漏洞 (bug) 。开发人员如果在程序中发现漏洞的存
8、在, 则必定会停止开发工作来修复漏洞, 或者投入专门的人力和物力进行漏洞修复。不论是哪种应对方案, 都会不可避免地消耗开发资源, 使开发成本变得更加昂贵, 直接导致开发软件的利润变得更小, 软件竞争力下降。在众多漏洞类型中, 安全性漏洞是软件开发者在软件维护与更新的过程中重要的关注点之一1-3。安全性漏洞是指能被攻击者利用, 以在计算机系统中获取未经授权的访问或进行超出权限的行为的一种软件漏洞, 会导致安全性缺陷, 使计算机系统陷入危险之中。安全性漏洞不一定会导致程序崩溃或停止运行, 但其一旦被攻击者利用, 则可能会造成不可挽回的损失。有时, 漏洞的修复不能一蹴而就, 开发人员也不可避免地会发
9、生修复漏洞错误的情况。开发人员完成漏洞修复之后会关闭漏洞, 但如果发现这个漏洞未被完全修复, 为了使之修复正确, 需要重新打开 (reopen) 该漏洞来对其进行再修复, 以避免在开发人员自认为修复正确的情况下, 安全性漏洞却悄悄造成重大的损失。Zaman 等人4发现, 安全性漏洞相比于其他漏洞更常发生再修复。因此, 对安全性漏洞的再修复进行研究, 找出再修复与初次修复的隐含关系, 对于安全性漏洞再修复的预测和提供修复意见十分重要。本文主要通过对 Mozilla 工程中发生再修复的安全性漏洞的各项数据进行统计分析, 找到安全性漏洞在再修复时存在的各种修复规律, 如修改文件和代码较为分散的安全性
10、漏洞较容易发生再修复, 一些类型的安全性漏洞再修复会包含初始修复的修改模式、修复过程和修改的文件与代码。这些规律可为开发安全性漏洞再修复预测和自动化修复的工具提供经验支持。本文第 2 节介绍经验研究的一些背景知识;第 3 节介绍研究的设计, 包括数据来源、研究的数据和数据分类方式;第 4 节给出对数据分析的结果以及得到的规律;第5 节介绍相关工作;最后总结全文。2 背景知识2.1 漏洞生命周期一个漏洞通常遵循图 15所示的生命周期。图 1 漏洞生命周期 下载原图一个漏洞在被发现后会被发现者报告出来, 此时漏洞发生的根本原因、漏洞类型等信息还不确定, 这便是未确认 (UNCONFIRMED) 阶
11、段。下一阶段就是通过错误信息对漏洞发生的原因进行分析, 如果是新的漏洞, 就进入这个新漏洞的各种信息获取阶段 (NEW and ASSIGNED) ;如果与已有漏洞相同, 就标注为重复 (DUPLICATE) 。获取完漏洞信息之后, 即对漏洞进行修复, 修复完成则进入解决 (RESOLVED) 阶段。解决阶段之后就是对修复进行验证 (VERIFIED) 的阶段, 该阶段主要负责验证修复是否正确, 最后关闭 (CLOSED) 漏洞。在解决阶段和关闭阶段之后, 都有可能因为修复不正确或不完整需要重新打开 (REOPENED) 漏洞来重新对其进行修复。这个重新打开阶段承担的工作就是本文要研究的安全性
12、漏洞再修复。2.2 安全性漏洞分类OSVDB (Open Sourced Vulnerability Database) 是一个为安全性漏洞提供准确、详细、及时、公正的信息的独立且开源的数据库。OSVDB 为安全性漏洞分类提供了参考。结合对数据的分析及 OSVDB 的参考分类, 我们将研究中的安全性漏洞分为 7 类6:信息泄露、拒绝服务攻击、跨站脚本攻击 (XSS) 、缓存溢出、内存泄露、使用非法内存及其他。信息泄露是指在程序运行过程中, 一些数据应该被保护或加密, 未经授权的用户不能得到这些数据, 但这些数据在某些安全性漏洞存在的情况下会被恶意用户获取, 从而给系统或正常用户造成损失。拒绝服
13、务攻击是指使目标电脑的网络或资源过载或耗尽, 从而使服务暂时中断或停止, 导致其对客户不可用。跨站脚本攻击是代码注入的一种, 指在网站应用程序中存在安全性漏洞恶意用户通过这些漏洞在网页中插入恶意代码, 而当用户进入、使用该网站时恶意代码会被执行。恶意代码包括 JavaScript, Java 等。恶意代码执行完之后, 可能会获取更大的权限, 窃取隐私信息等, 给正常用户造成影响和损失。程序在运行时都会分配一定大小的缓冲区, 而当写入的内容超过缓冲区大小时, 就会造成缓存溢出。若这种缓存溢出未被系统或程序察觉, 则攻击者可能破坏程序的运行、获得程序甚至系统的控制权, 进而运行恶意代码进行一些破坏
14、性的操作。内存泄露是指在程序中一些已经使用过且不再需要的内存未被释放, 使得程序的可用内存越来越少, 最后导致程序因缺少内存而使部分功能被迫停止, 甚至程序崩溃。这种内存的减少并不是物理上的内存减少, 而是可分配使用的内存数量越来越少。程序中经常使用指针来储存和操作数据, 但如果这些指针是空指针、指向地址已经被释放或指向程序堆栈之外即不属于程序的内存地址, 则会使程序停止运行或崩溃, 这就是使用非法内存。通过这些安全性漏洞分类, 可针对每类安全性漏洞进行分析, 研究各类安全性漏洞自身的特点。2.3 安全性漏洞的修改模式安全性问题通常是因为攻击者非法对数据进行访问而引起的。在对安全性漏洞的分析中
15、, 安全性漏洞的修复大多并不复杂, 根据程序系统对数据处理的 3 个阶段 (数据的预处理、数据处理、数据确保) 对安全性漏洞的修复, 总结了如表 1 所列的一些修改模式。表 1 安全性漏洞的修改模式 下载原表 在数据进入程序阶段, 即数据预处理阶段, 通常会对数据做一些检测和筛选, 来防止外部数据对程序进行攻击。在数据处理阶段, 即程序对数据进行操作的阶段, 需要保证数据被正确、安全地处理。在数据被程序处理完成后, 系统通常会根据这些数据输出一些我们想要的结果, 而这些结果也可能因为处理过程的不理想而出现一些错误。针对这种情况, 需要进行数据确保工作, 以防止错误的处理结果对程序造成影响。在数
16、据确保阶段, 最常用的修改模式是添加 IF 模块, 对结果进行判断, 确认其为正确合法的结果。安全性漏洞的修改模式相较于其他类型的漏洞更为简单, 通常是针对数据的修改。安全性漏洞的修改模式不涉及对软件功能性的修改, 只是对可能产生安全性问题的数据在程序传播的各个阶段进行检查、确认, 针对不同的安全问题与传播阶段添加相应的防护机制, 使数据的使用变得更加安全。同时, 安全性漏洞的修改模式更具通用性, 能够将相同的修改模式应用于不同的安全性漏洞的修复, 而非安全性漏洞则难以总结出一些统一的修改模式, 只能针对不同的功能模块得出不同的修改方法。针对以上修改模式, 可以观察安全性漏洞再修复与初始修复使用的修改模式之间的区别和联系。3 研究设计本文的研究主要围绕以下几个问题展开:(1) 安全性漏洞再修复的发生是否频繁, 以及与什么因素有关?(2) 哪种类型的安全性漏洞容易发生再修复且修复的难度较大?(3) 初始修复与再修复在修改模式、修复过程、修改内容方面有什么联系?3.1 数据来源
