分析android5.1

基于Clang编译前端的Android源代码静态分析技术①曹原野1,2,丁丽萍11(中国科学院软件研究所基础软件实验室,北京100190)2(中国科学院大学,北京100049)摘要:Android手机在全球占有很大的市场份额,基于Android衍生的第三方系统也为数不少.
针对Android系统重大安全问题频发的现状,提出一种使用Clang编译前端对Android源码进行静态分析的方法.
该方法从已公布的CVE漏洞中提取规则和模型,通过改进的Clang编译前端,对Android源码进行静态分析,从而检测出有潜在安全风险的代码片段.
在对Android源码进行污点分析时,调用新加入的stp约束求解器,通过符号执行,对敏感数据进行污点标记,并对敏感函数、敏感操作、敏感规则进行污点分析,如果存在潜在的安全隐患,则进行报告.
经过实验分析,该方法可以找出Android源代码中存在的同类型有安全风险的代码片段,可以检出libstagefright模块5个高危CVE漏洞.
关键词:Clang编译器;安卓;静态分析;污点分析;符号执行引用格式:曹原野,丁丽萍.
基于Clang编译前端的Android源代码静态分析技术.
计算机系统应用,2017,26(10):1–10.
http://www.
c-s-a.
org.
cn/1003-3254/6013.
htmlAndroidSourceCodeStaticAnalysisTechnologyBasedonClangCompilerFront-EndsCAOYuan-Ye1,2,DINGLi-Ping11(LabofFundamentalSoftware,InstituteofSoftware,ChineseAcademyofSciences,Beijing100190,China)2(UniversityofChineseAcademyofSciences,Beijing100049,China)Abstract:Androidphoneshavealargemarketshareintheworld,andthethird-partysystembasedonAndroid-derivedisalsoverypopular.
AsthesecurityissuesappearinAndroidsystemsfrequently,thispaperusesClangtocompileAndroidsourcecodeforstaticanalysis.
ThisanalysisextractsrulesandmodelsfrompublishedCVEvulnerabilities,andusestheimprovedClangtostaticallyanalyzeAndroidsourcecodetodetectpotentiallyunsafecodesnippets.
DuringtheanalysisoftheAndroidsourcecode,theClangstaticanalyzertaintsattacksurface,andcallsthenewaddedSTPconstrainedsolver.
Thenittaintssensitivedatathroughthesymbolicexecution,andmakestaintanalysisonthesensitivefunctions,sensitiveoperations,sensitiverules,finallyreportsunsafecodesnippetsiftherearepotentialsecurityrisks.
Throughexperimentalanalysis,thismethodcanaccuratelyidentifyunsafesourcecodesnippetsthatexistintheAndroidsourcecodewiththesametypeofsecurityrisk,andthismethodcandetectfivehigh-riskCVEvulnerabilitiesinthelibstagefrightmodule.
Keywords:Clangcompiler;Android;staticanalysis;taintanalysis;symbolicexecution1引言111Android系统因其开源性和开放性,在智能手机市场占有很大的市场份额.
近些年来,Android系统不断发展,在智能家电、物联网等领域迅速攻占市场,与人们的日常生活越来越紧密相关.
然而,Android系统的安全问题日益突出,不断爆出影响极大的安全漏洞,计算机系统应用ISSN1003-3254,CODENCSAOBNE-mail:csa@iscas.
ac.
cnComputerSystems&Applications,2017,26(10):110[doi:10.
15888/j.
cnki.
csa.
006013]http://www.
c-s-a.
org.
cn中国科学院软件研究所版权所有.
Tel:+86-10-62661041①基金项目:国家高技术研究发展计划("863"计划)(2015AA016003)收稿时间:2017-01-16;采用时间:2017-02-23SpecialIssue专论·综述1不仅影响了用户的使用体验,更严重威胁到了用户的隐私,例如:具备麦克风或摄像头的Android智能电视被远程控制,将会造成非常可怕的隐私泄露.
因此,Android硬件厂商在硬件发布之前,非常有必要对定制的Android系统进行安全审计,以尽可能地减少潜在的安全隐患.
对定制的Android源代码进行安全审计在保护用户的隐私、减少企业的开发成本方面有重要意义.
在研究Android源代码的CVE(Commonvulner-abilitiesandexposures)漏洞补丁的过程中,发现部分漏洞存在特定的规律和模式.
本文对这些规律和模式进行了总结分析,提出了一种基于改进的Clang编译前端进行安全分析的静态检测方法,该方法通过Clang编译前端对指定的Android模块进行符号执行[1,2],通过污点传播对敏感数据进行标记,通过对特定的函数[3,4]、条件分支、语法结构进行污点分析,找到有潜在安全风险的代码片段,并给出相应的检查报告.
企业在对Android系统进行定制修改之后,如果能够在系统发布之前,对Android定制系统的源代码进行安全审计,则可以有效降低定制系统的安全风险所带来的损失[5],同时因为审计的自动化,也可以大幅降低人力成本.
2相关研究代码审计的最终目标是挖掘软件中潜在的有安全风险的漏洞代码.
目前,针对Android系统的漏洞挖掘已经有很多成熟的方法.
例如:人工审查、模糊测试、动态分析、静态分析等方法.
人工审查就是通过人工阅读代码的方式对源代码进行逐行逐行地分析,判断是否有安全问题.
这要求审查人员有相当深厚的审查经验,而且很费时间,适用于简短但是易错的代码,如驱动代码.
模糊测试(Fuzz)是指通过给目标接口输入大量的随机数据,来测试接口是否能够正常处理这些畸形数据的测试方法.
如果接口或系统出现了异常,则认为接口极有可能存在缺陷.
模糊测试的优点是简单有效,但是相当耗费时间,因为是随机生成的数据,所以具有一定的概率性.
而且测试速率要受制于目标接口的响应速率.
对应的工具有Peach等.
Peach是一个遵守MIT开源许可证的模糊测试框架,用户通过编写PeachPit配置文件,可以定义Fuzz过程的配置和原始数据结构的定义.
通过定义原始数据结构生成结构化的部分随机数据,来实现精确的模糊测试.
动态分析是指对二进制程序进行插桩,来达到运行时对程序的控制和监控.
动态分析的优点是准确率高,覆盖面大,但是缺点是依赖于运行平台,有路径爆炸的风险,并且在编译过程中损失了一些代码的细节信息.
对应的工具有Pin、KLEE、Android_S2E[20]等.
Pin是Intel公司提供的二进制插桩工具[6],它允许在可执行程序的任何地方插入任意代码[7].
KLEE是一款源代码动态符号执行工具.
KLEE需要修改源代码,通过对源代码内特定的输入数据进行标记,插入自己的符号执行代码,然后编译执行并收集变量信息.
Android_S2E是一款全系统符号执行工具,它预装QEMU模拟器和KLEE在虚拟机上运行Android,并执行符号执行,可以遍历Android系统上小型C语言程序的所有路径.
静态分析是指在不运行代码的情况下,通过多种方式对源代码进行分析之后,得出源代码是否存在问题的结论.
分析方法涵盖简单的正则、词法分析、语法分析、上下文路径敏感分析等.
对应的工具有Coverity、Clang等.
Coverity是一个先进的、可配置的用于检测软件缺陷和安全隐患的静态代码分析解决方案,它能自动化地检测和解决C、C++、Java、C#源代码中多种类型的缺陷,Coverity对Android系统有针对性优化,但是Coverity是收费且闭源的.
Clang是LLVM开源编译套件的一个编译前端,负责将C、C++、Object-C源代码翻译为中间代码[8,9],而且Clang自身具备静态分析的能力,可以在不运行代码的情况下对代码进行编译分析.
现有Android系统安全问题的文献研究多数集中在Android应用层上的研究.
对于Android系统自身底层代码的安全研究的文献研究其实不常见[10,11].
移动安全会议上提到的工业界常用的方法多集中于模糊测试的方法.
使用模糊测试的方法虽然具有一定的随机性,但是简单便捷,并且短期内容易看到成效.
但是,安全研究员如果想要建立一种长效的安全机制,这种机制是稳定的,而且可以逐步完善、逐步归纳吸收已有的安全风险的话,使用静态分析是一种非常合适的方案.
静态分析没有模糊测试的随机性,分析结果比较稳定.
并且,通过对现有的安全风险进行归纳吸收,可以不断完善静态分析工具,那么静态分析工具就能够在检测能力上得到持续加强.
而一款能够持续加强的静态分析工具必须是开源的,所以本文主要调研了Clang计算机系统应用http://www.
c-s-a.
org.
cn2017年第26卷第10期2专论·综述SpecialIssue编译前端对Android源代码进行静态分析的难点.
本文经过调研,使用Clang成功对Android源代码进行了分析,并主要克服了3个方面的困难.
1)新版的Clang3.
8无法直接对Android源代码进行分析,需要做兼容处理.
2)Clang自带的约束求解器的求解能力过弱,不适合应用在Android源代码这种复杂项目上.
3)Clang自带的检测规则是通用检测规则,没有针对Android源代码的检测规则,导致检测能力过弱.
本文克服了上述3个困难,最终实现了目标:实现一种工业界可用的,基于改进的Clang编译前端的,用于Android系统源代码的静态分析方法.
3基于Clang编译前端的静态分析原理Clang作为LLVM编译套件的编译前端,自带一个静态代码分析工具,可以编译分析C、C++、Object-C源代码,此静态分析工具属于Clang的一部分因而完全开源.
Clang在对源代码进行编译的时候,会通过静态分析,对代码风格、语法错误和潜在的风险进行warning警告.
Clang静态分析器通过自定义代码可以实现更复杂的检测机制来进行静态分析.
Clang的静态分析器首先通过程序代码,生成AST(语法树),然后根据AST生成CFG(控制流图),通过符号执行生成扩展图(ExplodedGraph),具体控制流程如图1[12]所示.
图1Clang的静态分析过程通过自定义Checker(Clang中的检查器,用来检测自定义缺陷),可以实现对AST和ExplodedGraph的分析和控制.
Checker不仅仅只能是被动的调用,Checker也能主动地修改ExplodedGraph.
如果Checker认为存在特定的缺陷,就可以调用BugReport来报告存在的缺陷,方便测试人员可视化地观察检测信息.
Clang的AST树近似于常规的编程语法结构.
通过"clang-Xclang-ast-dumpexample.
cpp"可以对源代码生成的AST进行观察.
AST语法树主要由两类结点(Stmt与Decl)和派生自他们的子结点构成.
Stmt是指statement语句,Decl是指declarations声明.
Clang的CFG控制流图由若干个CFGBlock块组成,每个CFGBlock均包含有EXIT块和ENTRY块.
并且每个CFGBlock块由一组CFGElement组成,其中的CFGElement代表AST树中的一个结点.
Clang的ExplodedGraph图是在通过符号执行遍历CFG图的时候产生的.
ExplodedGraph中的每个结点,都包含了ProgramPoint点和State信息.
Program-Point点,用来定义源代码运行到该点时所有变量的值.
State信息用来表示源代码在符号执行过程中的状态信息,包括:表达式到值的映射关系、各种变量到值的映射关系、路径条件约束等信息.
通过Clang的源码,可以发现,如果将Clang的静态分析直接应用到Android系统源码之上,基本没有效果.
一个原因是Clang自带的range约束求解器的求解能力过于薄弱,只能处理简单约束.
另一个原因是Clang作为一个通用编译前端,更注重的是通用性,所以特定问题的检测能力不强.
需要对Clang的符号执行能力和检测能力进行增强.
所以,以下小节将逐个描述对Clang进行加强的实现原理.
3.
1改进Clang静态分析Android源码的兼容性Android源码内,含有LLVM的预编译工具链,但是直到最新的Android7.
1的源代码,LLVM预编译工具链中Clang的版本仍旧是3.
3版本.
本文需要定制较新的Clang3.
8版本进行静态分析.
所以需要了解Clang静态分析指令和Android源代码的编译脚本工作原理.
Clang静态分析由两个指令构成,分别是"scan-build"和"scan-view"命令.
"scan-build"命令后面紧接着正常的编译命令,例如"scan-buildg++example.
cpp"或者"scan-buildmake-j4"这种编译命令.
其中"scan-build"命令会对后面的编译命令进行分析,替换其中的编译器为Clang本身,则Clang可以顺利地进行静态分析.
"scan-build"在分析完毕之后,会留下一个特殊的目录,使用"scan-view"打开这个目录,则可以显示分析报表.
Android源代码的编译脚本主要集中在源代码根目录的build/envsetup.
sh文件里.
其中主要有4个编译命令,分别是mmm、mm、m、make命令.
mmm命令主要用于编译指定路径下的模块,mm命令用于编译当前路径下的模块,m命令编译当前目录下的所有模块,make命令则是编译整个Android系统.
为了静态分析的需要,主要进行单个模块的分析,所以选用mmm命令.
通过更换mmm命令后的路径,可以实现不同模块的静态分析.
"mmmpath-B"其中的"-B"参数则是无论2017年第26卷第10期http://www.
c-s-a.
org.
cn计算机系统应用SpecialIssue专论·综述3源码修改与否都强制编译path目录下的所有源码.
直接使用"scan-buildmmmpath-B"则会直接报错.
通过研究envsetup.
sh的代码,发现在getdriver函数声明了静态分析的使用规则和"scan-build"的二进制路径,将getdriver函数的"scan-build"路径改为改进的Clang源代码生成的"scan-build"路径.
同时执行"WITH_STATIC_ANALYZER=1mmmpath-B"则可成功启动改进Clang的静态分析.
但是,分析途中一定会出错,因为高版本的Clang已经不支持一些旧命令参数,所以需要对"scan-build"编译脚本调用的其他编译脚本进行兼容修改.
经过修改的的编译脚本可以正确对某个模块进行静态分析.
3.
2增强Clang的符号执行能力SMT(Satisfiabilitymodulotheories)可以用来解决逻辑公式的决策问题[13],可以用来处理布尔运算、量词、算术运算、比较运算、位运算等约束性求解问题.
SMT模型有一些具体的约束求解器实现,例如:z3约束求解器、stp约束求解器等.
这些求解器具备强大的求解能力,可以处理编程语言中常见的复杂条件判断、位运算、数组操作等.
符号执行是CFG生成ExplodedGraph时使用的.
Clang静态分析程序读取CFG,当遇到条件分支时,会根据不同的条件分支,依次执行不同的条件分支.
在执行不同的条件分支之前,符号执行会把进去当前分支所需要的条件放入约束求解器查询,如果当前条件满足约束求解器,则执行分支并把分支条件放入约束求解器,否则不执行当前分支.
Clang具备符号执行的能力,但是其自带的range约束求解器能力不强,只支持简单约束条件,遇到多元约束条件不能处理则忽略,这大大削弱了符号执行的准确性.
在实际的复杂代码中,这个自带的约束求解器在精度方面经常不能满足预想的要求.
但是Clang本身支持约束求解器的扩展,可以通过仿照range约束求解器的编写方式,修改Clang配置文件,增加新的约束求解器,达到增强约束求解器的目的.
本文通过修改Clang源码,加入了stp约束求解器,使Clang可以处理复杂的多元约束求解.
通过增强Clang符号执行的约束求解能力,提高其检测精度.
3.
3增强Clang的静态检测能力作为一款通用编译前端,Clang所面对的是通用场景的代码.
其静态分析里的检测规则面向的是常见的缺陷问题.
所以,Clang对于特殊模式的问题无法进行正确检测而得出结果.
于是,在使用Clang对Android的源码进行分析之前,需要预先增强Clang的静态检测能力.
对于Android系统,如果Clang想要检测出安全风险,就需要预先知道可能的攻击面.
Android系统因为丰富的交互功能,其本身具有很多潜在的攻击面.
攻击面可以分为4类.
1)远程攻击面:主要包含了网络协议栈、对外暴露的网络服务、短信、彩信、基础软件(浏览器接口、多媒体和文档处理、电子邮件)等.
2)物理相邻的攻击面:无线、蓝牙、NFC等.
3)本地攻击面:文件系统、系统调用等.
4)物理连接攻击面:USB连接等.
可被用户控制的数据从这些攻击面,流入到系统的控制流中,如果处理不当,则可能会引入安全风险.
所以,静态分析的主要目标,就是需要频繁从攻击面获取数据的模块,例如:libstagefright模块.
为此,需要设定一段污点传播程序,对Android源码中有可能从攻击面引入的危险数据加上污点标记.
并对污染的数据进行污点传播,即图2的"敏感函数污点标记".
敏感函数例如:内存操作函数、网络操作函数、缓冲区管理函数、文件管理函数等.
图2增强的静态检测逻辑在Android源代码里,充满了大量的宏定义和复杂的工具类,给开发人员带来了巨大的便利,但是也给开发人员带来了困扰:有时候会不记得当前的变量到底是什么类型,有时候会忘记一些必须的操作.
以下总结一些在Android源代码漏洞中常见的错误模式.
(1)敏感函数的参数错误计算机系统应用http://www.
c-s-a.
org.
cn2017年第26卷第10期4专论·综述SpecialIssuememcpy(dest,src,len);在复杂逻辑中,开发人员可能会忽略对len的正确约束,导致len可以赋值为一个超大的整数值.
(2)隐式转换memcpy(dest,src,len);在开发中,开发人员混淆了len的类型,直接将有符号数直接传入参数,同时没有限制len必须大于等于0.
longlonga=int_b+int_c+(longlong)d;在开发中,遇到一个复杂计算式,而且数据类型不一致时,开发人员意识到需要进行强制类型转换.
但是强制类型转换过晚,int_b和int_c已经发生了溢出并进行了隐式转换之后,才与d变量进行相加.
(3)分支条件if(int_e+100进行拦截判断,通过对Expr的判断,抽取其中的隐式转换和显式转换,进行分析.
"分支条件判断污点"可以通过check::CheckBranchCondition对条件分支进行拦截,并对其中的Stmt进行判断.
表1Clang的路径敏感分析接口分析接口名称调用时机check::PreStmt声明之前调用check::PostStmt声明之后调用check::PreCall调用接口之前调用check::PostCall调用接口之后调用check::Location读写变量时调用check::Bind绑定变量时调用check::BranchCondition发生条件分支时调用check::EndAnalysis整体分析结束时调用check::EndFunction函数分析结束时调用check::LiveSymbols垃圾回收之前调用check::DeadSymbols完成垃圾回收之后调用check::PointerEscape指针不能追踪时调用check::RegionChanges内存操作时调用eval::Assume有新的条件约束之前调用eval::Call函数过程分析之前调用图2中的"溢出判断"可以通过Clang内置的SValBuilder类的evalBinOpNN方法对污点变量的范围进行估计,测试污点变量是否经过正确约束.
图2中的"规则判断"则可以通过ASTContext类的getParents(node)方法获取父节点,或者通过node本计算机系统应用http://www.
c-s-a.
org.
cn2017年第26卷第10期6专论·综述SpecialIssue身自带的各种方法获取其子结点.
甚至可以使用Clang内置的RecursiveASTVisitor类实现对某个结点的子结点进行自动递归查询.
4.
4漏洞代码的特征分析及处理代码6展示了CVE-2015-1538的部分补丁.
代码6.
CVE-2015-1538部分补丁代码mTimeToSampleCount=\U32_AT(&header[4]);-uint64_tallocSize=\mTimeToSampleCount*2*sizeof(uint32_t);+uint64_tallocSize=\mTimeToSampleCount*2*(uint64_t)sizeof(uint32_t);代码6中的缺陷存在着固定的模式:污点数据由uint32类型参与运算提升为uint64类型,但程序员没有意识到溢出发生在类型的隐式转换之前.
所以引入了潜在的溢出风险,故补丁加入了强制转换.
但是,代码6里的补丁仍旧是错误的!
这导致了后序的漏洞CVE-2015-6601.
仔细观察代码6中的补丁,程序员的补丁里显然意识到了污点数据隐式转换的危险性,但是程序员忘记了计算是从左到右执行的.
强制转换太迟了,污点数据仍旧可以先溢出,再提升类型.
如代码6所示,U32_AT是libstagefright从缓冲区读取数据的公共方法,类似的还有U16_AT、U64_AT.
U32_AT函数会触发图2中的"敏感函数污点标记",使mTimeToSampleCount变量被标记.
代码6中对allocSize的赋值操作中,实际上发生了类型提升(未打补丁是隐式提升,打了错误的补丁是显式提升).
如果表达式中包含污点数据且存在类型提升,则Chekcer触发图2中的"污点数据类型转换"会对其中的类型转换进行检查.
代码7展示了CVE-2015-6604的部分补丁.
代码7.
CVE-2015-6604部分补丁代码returnfalse;}-if(offset+dataSize+10>mSize){+if(dataSize>mSize-10-offset){returnfalse;}代码7中的缺陷存在着固定的模式:在一个条件分支语句中,程序员忽视了污点数据的存在,过分相信变量,直接让污点数据参与了计算,之后再参与比较判断.
如代码7所示,其中dataSize的数据,由U32_AT方式获取,故被标记为污点数据.
但是在if条件判断语句中,因为条件判断表达式含有污点数据,故触发图2中的"分支条件判断污点",对条件表达式进行求值分析.
4.
5Clang的报告生成在4.
3章中使用Clang的Checker对待检测代码进行分析之后,如果发现潜在的问题,则使用Clang自带的BugReport进行风险代码的报告.
通过定义一个自定义BugReport,可以实现特定格式内容的Bug报告.
在分析结束之后,通过scan-view命令打开分析报告网页,对分析结果进行查看.
5实验及结果分析5.
1试验环境本文使用Ubuntu16.
04LTSX64操作系统,处理器Intel酷睿i74750HQ(3.
2GHz),16GB内存,80GB交换分区,1000GB机械硬盘.
基于Clang3.
8进行测试修改.
静态分析期间,不同时运行其他程序,以免影响时间和内存使用的实验结果.
Clang运行参数方面,除了第3章节所做的代码修改和实验过程中输入的动态参数,其余配置保持默认参数不变.
因为符号执行会出现路径爆炸问题,Clang会使用一个默认最大循环执行次数来进行限制,默认值是4,本实验不修改.
5.
2使用测试集对改进后的Clang进行验证经过改进的Clang不能直接用于Android系统的代码分析,需要首先确保修改的正确性,保证改进后的Clang编译前端本身没有逻辑错误.
一个错误的Clang编译前端在分析Android源代码时的结果是不可信的.
而改进的Clang编译前端的代码修改集中在符号执行和整形溢出检测上,所以需要一组整形溢出测试集验证Clang的符号执行精度和整形溢出检测能力.
测试集的选取,选用的是从NIST网站下载的美国NSA(Nationalsecurityagency)开发的Juliet_Test_Suite[24]测试集.
Juliet_Test_Suite测试集包含多种CWE(Commonweaknessenumeration)[16]类型的常见漏洞代码.
本实验选取其中的"CWE190_Integer_Overflow"测试集.
其测试集下总共有5种类型的子测试集,分别编号S01,S02,S03,S04,S05.
通过特定的宏定义,可以调整测试集的检测特性.
2017年第26卷第10期http://www.
c-s-a.
org.
cn计算机系统应用SpecialIssue专论·综述7如:只检测存在有安全缺陷的函数、只检测不存在安全缺陷的函数、检测全部函数.
表2显示了5个子测试集的函数用例数量.
表2测试集溢出漏洞用例数量(个)安全用例数量不安全用例数量S01550550S02550550S03550550S04550550S05500500测试过程中,采用子测试集逐个进行测试的方式执行.
单个子测试集在测试的时候,分为六次测试.
前两次使用未修改的原生的Clang且使用自带的range约束求解器分别测试安全函数和不安全函数.
中间两次使用改进的Clang且使用自带的range约束求解器分别测试安全函数和不安全函数,后两次使用改进的Clang且使用新加入的stp约束求解器分别测试安全函数和不安全函数.
运行静态分析的时候,记录分析所需要的时间,并分析所得到的结果,测试所需时间如表3所示.
其中,good_origin_range指原生的Clang使用自带的range求解器只检测安全函数,good_improved_range指改进的Clang使用自带的range求解器只检测安全函数,good_improved_stp指改进的Clang使用新加入的stp求解器只检测安全函数.
bad_origin_range,bad_improved_range,bad_improved_stp指相同的情况下只检测不安全函数.
表3静态分析所需时间(秒)S01S02S03S04S05good_origin_range122119118118108good_improved_range299328318301283good_improved_stp321355360324307bad_origin_range10510710610496bad_improved_range273296297276258bad_improved_stp284309306287269通过表3分析发现,不管是只检测安全函数还是只检测不安全函数,在都使用自带的range求解器的情况下,改进的Clang比原生的Clang检测时间增长了约两倍,这是因为改进的Clang增加了污点传播等更多的检测规则,导致检测时间的增大.
同样是改进的Clang,使用新增加的stp求解器比使用range求解器耗费的时间都要多,但是基本不多于10%,这是因为stp的求解能力更强,规则更复杂,导致了耗费时间的增加.
表4中"good_origin_range"和"bad_origin_range"分别指原生Clang使用自带的range求解器测试安全用例和不安全用例的情况.
通过测试发现,基本只能找到"Deadassignment","Deadinitialization","Memoryleak"这三种错误.
不管是安全测试用例还是不安全测试用例,均无法检出任何溢出漏洞.
这是因为原生的Clang本身无对应的检测规则.
表4检出溢出类型漏洞数量(个)S01S02S03S04S05good_origin_range00000good_improved_range568590653568569good_improved_stp4584634563bad_origin_range00000bad_improved_range363452453363404bad_improved_stp9916211599115表4中的"good_improved_range"和"good_improved_stp"分别指改进的Clang使用自带range求解器或stp求解器分别对安全用例的检测情况.
改进的Clang,因为检测规则的增加,已经可以检测溢出漏洞.
但是,安全测试用例中是没有不安全的用例的.
所以,通过比较,在使用range求解器的情况下,有超高的误报,而stp的误报则是非常的低.
具体原因是range求解器的能力过弱,很多复杂约束不能处理,导致实际上没有成功加入约束条件,导致了大量的误报.
其中误报的数量甚至超过了测试用例的数量,一个原因是某些用例有多种测试方法,此外如图2所示,改进的Clang有3种触发方式进行缺陷分析,一个函数由若干行的代码构成,所以一个函数体可能检出不少于1个漏洞.
不安全测试用例在源代码的对应代码行的注释中,进行了标注.
表4中的"bad_improved_range"和"bad_improved_stp"分别指改进的Clang使用自带range求解器或stp求解器分别对不安全用例的检测情况.
通过对测试报告的排查,stp求解器虽然检出的结果比较少,但是非常准确.
range求解器检出的结果存在大量的误报,将测试用例的源代码中,没有标记为缺陷位置的代码检测为存在缺陷.
收集测试用例的静态分析结果,同时收集静态分析日志,结合在一块进行分析,可以得出结论:stp求解器虽然在时间耗费上比range求解器稍多,但是在约束求解精度上,stp求解器有很大的提高;同时结合静态分析日志和测试用例源代码,对比stp求解器的约束区间,可以发现求解器计算出了正确约束区间.
计算机系统应用http://www.
c-s-a.
org.
cn2017年第26卷第10期8专论·综述SpecialIssue5.
3使用改进的Clang编译前端对Android源码进行分析参考第4节的"Android代码静态分析的实现"里的实现,整个Android源代码在编译和修改完毕之后,运行代码8里的指令,即可使用改进的Clang且使用stp约束求解器对Android源码进行静态分析.
代码8.
执行静态分析$sourcebuild/envsetup.
sh$lunchaosp_arm-eng$WITH_STATIC_ANALYZER=1mmmmodel_path-B本实验主要通过"WITH_STATIC_ANALYZER=1mmmframeworks/av/media/libstagefright/-B"对Android源代码的libstagefright模块进行分析.
通过对Android不同版本的源码进行静态分析,对于未打补丁的源码可以找出以下高危漏洞,其漏洞CVE编号分别如下:CVE-2015-1538,CVE-2016-6601,CVE2015-3832,CVE-2015-3831,CVE-2015-6604.
图3CVE-2015-1538漏洞检测结果界面5.
4分析过程的时间复杂度、空间复杂度及优化本实验的分析工具在时间复杂度上耗时较大,分析简单的libmedia模块需要十几分钟,但是分析复杂的libstagefright模块就需要几十个小时.
通过使用linux下的perf性能调优工具对分析过程(不能直接分析第5.
3节中的mmm命令,分析mmm函数解析后的命令)进行分析,发现耗时的TOP-50函数均是来自libstp.
so和libminisat.
so里的函数,两个库文件里的函数总共占用了95%以上的运行时间.
其中libstp.
so是分析工具所依赖的STP求解器的库文件,libminisat.
so是libstp.
so所依赖的库文件.
运行时间主要耗费在求解表达式.
本实验的分析工具在空间复杂度上耗费也较大.
如分析libmedia模块需要1–2GB内存,分析libstage-fright模块需要2–4GB内存,短时间会使用16GB以上内存.
通过使用linux下的gdb和valgrind内存分析工具对分析过程进行分析,主要发现libstp.
so库文件与加入的STP求解器代码存在内存泄露问题,其中存在少数没及时释放的大内存块,导致了大量的内存占用.
针对时间复杂度和空间复杂度的问题,对本实验的分析工具进行对应的优化,在加入的STP求解器的代码部分,加入了遗漏的释放资源的代码,降低内存占用,减少了部分内存泄露.
同时对Checker里的检测代码进行优化,尽量用循环来取代递归,同时将符号执行里的污点数据按照符号执行地址存放在公共map数据结构里,进行加速,以此节约内存和时间.
6结语本文提出了使用改进的Clang对Android源代码进行静态分析的研究和实现,通过新增Clang的约束求解器并对静态检测功能进行改进,实现了对Android部分类型漏洞的静态分析检测,并成功检测到部分漏洞.
最终实现了可用的对Android源代码进行分析检测的实用静态分析工具.
但是分析工具自身还存在一些问题,例如:时间耗费较长、内存耗费较大,经过第5.
4节的优化,解决了部分问题,但是内存泄露问题没有彻底去除,耗时仍旧偏长;此外静态分析自身的符号执行存在一定偏差,面对特别复杂的约束条件和调用过程,不能准确地进行约束求解.
而且,图2的"溢出判断"中的判断方法有些粗糙,容易造成漏报,"溢出判断"需要对加减乘除等各种情况进行仔细地处理,这些处理需要大量的细节进行完善.
参考文献DietzW,LiP,RegehrJ,etal.
UnderstandingintegeroverflowinC/C++.
ACMTrans.
onSoftwareEngineeringandMethodology(TOSEM),2015,25(1):2.
1BushWR,PincusJD,SielaffDJ.
Astaticanalyzerforfindingdynamicprogrammingerrors.
Software-Practice&Experience,2000,30(7):775–802.
2SchmidtD,SteffenB.
Programanalysisasmodelcheckingofabstractinterpretations.
InternationalStaticAnalysisSymposium.
Pisa,Italy.
1998.
351–380.
3CadarC,DunbarD,EnglerD.
KLEE:Unassistedand42017年第26卷第10期http://www.
c-s-a.
org.
cn计算机系统应用SpecialIssue专论·综述9automaticgenerationofhigh-coveragetestsforcomplexsystemsprograms.
Proc.
ofthe8thUSENIXConferenceonOperatingSystemsDesignandImplementation.
SanDiego,California,USA.
2008.
209–224.
KremenekT.
FindingSoftwareBugswiththeClangStaticAnalyzer.
California:AppleInc,2008.
5XuZX,KremenekT,ZhangJ.
AmemorymodelforstaticanalysisofCprograms.
InternationalSymposiumonLeveragingApplicationsofFormalMethods,VerificationandValidation.
Heraklion,Crete,Greece.
2010.
535–548.
6KhedkerU,SanyalA,SatheB.
DataFlowAnalysis:TheoryandOractice.
BocaRaton,FL:CRCPress,2009.
7XuZB,ZhangJ,XuZX.
Melton:ApracticalandprecisememoryleakdetectiontoolforCprograms.
FrontiersofComputerScience,2015,9(1):34–54.
[doi:10.
1007/s11704-014-3460-8]8RepsT,HorwitzS,SagivM.
Preciseinterproceduraldataflowanalysisviagraphreachability.
Proc.
ofthe22ndACMSIGPLAN-SIGACTSymposiumonPrinciplesofProgrammingLanguages.
SanFrancisco,California,USA.
1995.
49–61.
9LiuT,HuuckR.
Casestudy:Staticsecurityanalysisoftheandroidgoldfishkernel.
InternationalSymposiumonFormalMethods.
Oslo,Norway.
2015.
589–592.
10MunteanP,RahmanM,IbingA,etal.
SMT-constrainedsymbolicexecutionengineforintegeroverflowdetectioninCcode.
Proc.
of2015InformationSecurityforSouthAfrica(ISSA).
Johannesburg,Azania.
2015.
1–8.
11WangTL,WeiT,LinZQ,etal.
IntScope:AutomaticallydetectingintegeroverflowvulnerabilityinX86binaryusingsymbolicexecution.
Proc.
oftheNetworkandDistributedSystemSecuritySymposium.
SanDiego,California,USA.
2009.
12CadarC,GodefroidP,KhurshidS,etal.
Symbolicexecutionforsoftwaretestinginpractice:Preliminaryassessment.
Proc.
ofthe33rdInternationalConferenceonSoftwareEngineering.
Honolulu,HI,USA.
2011.
1066–1071.
13SuiYL,YuD,XueJL.
Staticmemoryleakdetectionusingfull-sparsevalue-flowanalysis.
Proc.
ofthe2012InternationalSymposiumonSoftwareTestingandAnalysis.
Minneapolis,14MN,USA.
2012.
254–264.
LiL,CifuentesC,KeynesN.
Practicalandeffectivesymbolicanalysisforbufferoverflowdetection.
Proc.
ofthe18thACMSIGSOFTInternationalSymposiumonFoundationsofSoftwareEngineering.
SantaFe,NewMexico,USA.
2010.
317–326.
15SuiYL,XueJL.
SVF:Interproceduralstaticvalue-flowanalysisinLLVM.
Proc.
ofthe25thInternationalConferenceonCompilerConstruction.
Barcelona,Spain.
2016.
265–266.
16EnckW,GilbertP,HanS,etal.
TaintDroid:Aninformation-flowtrackingsystemforrealtimeprivacymonitoringonsmartphones.
ACMTrans.
onComputerSystems(TOCS),2014,32(2):5.
17ArztS,RastofherS,FritzC,etal.
Flowdroid:Precisecontext,flow,field,object-sensitiveandlifecycle-awaretaintanalysisforandroidapps.
ACMSIGPLANNotices,2014,49(6):259–269.
[doi:10.
1145/2666356]18HorváthG,PatakiN.
ClangmatchersforverifiedusageoftheC++standardtemplatelibrary.
AnnalesMathematicaeetInformaticae,2015,44:99–109.
19Android的全系统符号执行工具-Android_S2E.
http://www.
infoq.
com/cn/presentations/whole-system-symbol-Implementation-tools-android-s2e.
[2017-01-05].
20LattnerC,AdveV.
LLVM:Acompilationframeworkforlifelongprogramanalysis&transformation.
Proc.
InternationalSymposiumonCodeGenerationandOptimization.
SanJose,CA,USA.
2004.
75–86.
21SpreitzenbarthM,SchreckT,EchtlerF,etal.
Mobile-sandbox:Combiningstaticanddynamicanalysiswithmachine-learningtechniques.
InternationalJournalofInformationSecurity,2015,14(2):141–153.
[doi:10.
1007/s10207-014-0250-0]22ZhangJX,LiZJ,ZhengXC.
PathWalker:AdynamicsymbolicexecutiontoolbasedonLLVMbytecodeinstru-mentation.
InternationalSymposiumonDependableSoftwareEngineering:Theories,Tools,andApplications.
Nanjing,China.
2015.
227–242.
23SoftwareAssuranceReferenceDataset.
https://samate.
nist.
gov/SRD/testsuite.
php.
[2016-11-10].
24计算机系统应用http://www.
c-s-a.
org.
cn2017年第26卷第10期10专论·综述SpecialIssue