BScout: Direct Whole Patch Presence Test for Java Executables

Jiarun Dai, Yuan Zhang, Zheyue Jiang, Yingtian Zhou, and Junyan Chen, Fudan University; Xinyu Xing, Pennsylvania State University; Xiaohan Zhang,Xin Tan, Min Yang, and Zhemin Yang, Fudan University

USENIX 2020

Abstract

为了终端用户和软件的安全着想、及时对受影响的安全漏洞进行补丁非常重要。在这种前提下,补丁存在测试尤其重要,能在没有源代码的目标程序中分析补丁是否存在。现有的方式都是基于特征的分析方法,特征来源于一小段补丁代码,不可靠程度高。

提出BScout,直接的检查Java可执行文件中是否存在整个补丁,并且不需要生成补丁特征。BScout用了几种新的技术来建立源代码与字节码结构的连接,并会在执行过程中分析补丁的细粒度语义。

使用194个CVE存在于安卓框架于第三方库中的漏洞来进行测试,最后显示了很好的准确度。并将BScout用在七个厂商的2506个安卓系统上进行大型测试,发现了很多没有被报告的问题。

Introduction

开发者使用开源库与代码来开发闭源项目是很常见的事情,研究表明,开源项目通常存在很多漏洞会引入到闭源的项目中。为了避免这种情况,知道当前的开源软件中是否已经修复了漏洞是很必要的。--- 补丁存在测试(patch presence test)。

现有工作:

  • 漏洞代码搜索:通过函数级别或者镜像级别进行代码定位与代码差异分析,这种方法因为粒度不精准会造成大量的误报。
  • 漏洞检测方式:src2src、bin2bin,没有存在src2bin的
  • FIBER:用于检测C/C++二进制文件中是否存在补丁修复。首先建立二进制表示上的漏洞特征,然后去目标的二进制中去匹配特征。局限性:只在小部分本地化的补丁段上生成了特征,没有生成整个补丁的特征,因此不可靠。并且使用了精准匹配的方法来找补丁,对于一些对补丁修改的部分无法识别。因此只能在八个二进制目标上运行,并且报出了很多误报。同时还要求需要构建全程序的bin2src的特征生成,还需要选择与被测目标最近的镜像文件发布时间最近的版本,限制很大。

目标工具的特性:鲁棒性、高精度、灵活性

  • 鲁棒性:补丁存在测试需要依赖整个补丁而不是补丁的一小部分作为特征
  • 高精度:不管补丁有没有存在,都应该准确的报出状态
  • 灵活性:不用完全依赖于目标的全部源代码的特征构建过程

BScout:

  • 使用整个补丁识别漏洞是否存在,构建Java字节码对应源代码的链接表示,并不需要特征构建。
  • 使用字节码的原因:java字节码文件无处不在;现有的补丁识别工作没有针对java字节码的;java字节码携带的信息有利于用来进行补丁存在测试

技术挑战

  1. 安全补丁可能会只有细微的修改,需要为补丁和目标之间建立更细粒度的连接。
  2. 因为java源代码和java字节码之间的语言表示完全不同,很难建立一个跨层级的测试
  3. 一些补丁代码可能会存在多次,因此不仅仅需要检查代码是否存在,还需要对次数的检查。
  4. 补丁中可能存在多种修复方式,增加或者删减,需要使用多种检测策略。

基本思路

收到行级补丁生成工作和实践的启发,可以检测目标执行程序中补丁行的微小修改。

为了实现行级别的补丁检测测试,首先使用了跨层级的行级别关联分析(cross-layer line-level correlative analysis):通过收集字节码结构与源代码层级的代码特征,然后将一行源代码与几行字节码文件关联起来。

BScout使用字节码中的行号信息将字节码进行切割,然后利用基于学习的指令分割来切断字节码的边界,整个函数的基础上执行线性相关分析,探测补丁代码存在的次数。

补丁差异分析(patch-derived differential analysis):添加、删除、复合。在补丁前源代码和补丁后源代码中提取差异来去目标中测试。

实验结果

在安卓框架和第三方java库中找了194个CVE进行实验,实验目标是15个安卓系统镜像,261个安卓app和28个桌面/服务端app。BScout的依赖行号信息精准度达到100%,不依赖行号信息精准度达到了96.9%,观测到现有的方法都表现了较差的性能。

同时还对来自7个厂商的2506个安卓ROM进行测试,有一些新的发现:

  1. 谷歌通常在向公众公开漏洞之前就及时的修复漏洞,其他的厂商则较慢
  2. 漏洞严重程度和补丁的复杂性都不会影响补丁
  3. 厂商没有对受所有影响的手机型号提供补丁
  4. 几乎所有的厂商都夸大了安全补丁的级别,只有大概9.4%正确报告出安全级别

contributions

  • BSCOUT:新的工具可以检测java执行程序中的补丁存在
  • 使用真实的样例来测试工具,并展示了良好的精准度与有效性
  • 进行大规模的实验,并有一些新的有趣的发现

Challenges and Insights

使用安卓框架中的CVE-2016-3832的补丁作为样例来说明补丁存在测试中存在的挑战,以及对应的解决办法。

java执行文件中存在两种字节码格式:基于栈的传统java字节码和DEX字节码。因为DEX字节码可读性更强,因此将java可执行文件使用dx转换成DEX字节码。图一展示的是补丁的代码片段以及两个和他相似的java可执行文件字节码(使用DEX字节码)。

首先发现补丁代码中存在三行添加行代码并且一行删除行代码,13-14行其实是一行语句分成了两行代码编写,因此使用13作为这两行代码的表示。根据[31]发现,安全补丁相比于普通的bug修复会引入更少的代码修改。(Challenge I),应对方式是,对有安全修复中的每一行都应该从目标字节码中找到对应的表示。

因为在字节码中不会存在完整的源代码语句,因为语义表述不同,(Challenge II),使用smali表示的语义特征尝试推断和源代码的等价性。例如:第七行的readInt()函数调用的返回值赋值给userId这个变量,我们可以找到在第一个目标字节码片段中,line1585和1587中都存在readInt()函数调用,以及第二个片段中的1584可以找到同样的函数调用。因此可以通过类似的线性分析,找到对应字节码中的可以链接上的候选smali指令。

根据上述的表示,会将源代码的添加行7行链接到三个位置,会将下边两个代码片段都标注为已经修复。但是发现在补丁文件中第五行也同样可以链接到相同的三个位置,而且第五行是在补丁之前就存在的代码,然后会将第五行和第七行同时考虑,发现在第一个片段中两个都有找到,第二个片段中只发现一个匹配情况。(Challenge III),因此可以处理为第一个片段为已经修复,第二个片段为未修复的目标。同时也会发现,对于这种补丁代码在函数中多次出现的情况,只使用补丁代码不能很好的进行判断与区分。因此,对于补丁中的添加行,最好使用整个补丁来进行测试

对于12行和13行,发现他们使用相同的方法调用bindBackupAgent(),通过线性的分析,会都链接到两个片段中的2238行位置。因为12行是删除行,13行是增加行,因此会分析12行的时候将两个片段都作为未修复的片段,分析13行的时候都作为已修复的片段。是因为没有识别到12行和13行的关系,他们修复的是同一行代码,(Challenge IV),然后发现是修改了参数个数,又原来的两个变成了三个,将这个元素考虑进去之后,会发现第一个代码的2238行和补丁行更接近。

综上分析,第一个字节码片段为未修复,第二个片段为已修复。在上述说明中使用行号来进行样例说明,但是在工具中不一定会使用行号进行匹配。

BScout Approach

图2如下,包含框架的整体示意图

步骤一:跨层级行级相关性分析( Cross-layer Line-level Correlative Analysis.)选取补丁前和补丁后的源代码以及目标代码作为INPUT,生成两个line2line的可以表示字节码对应源代码的图结构作为OUTPUT,

步骤二:补丁存在差异分析(Patch-derived Differential Analysis)基于上一步骤生成的两个图结构,分析补丁中的细粒度变化,来用于分析补丁是否已经修复。首先区分成三类不同的行、增加行、删除行、复合行,然后对于每一种变化的行都进行不同的分析,来进一步确认是否修复。

3.1 Feature Extractor

使用现有的定理证明技术很难关联字节码和源代码的关系,本文使用字节码和源代码都共有的部分结构和语义特征来进行关联。

3.1.1 Feature Set

提取的特征需要两种特性:

  • 语言无关性(Language-independent.):被选取的特征需要同时存在于源代码与smali代码中,例如:临时变量名只存在于源代码,因此不能作为特征。
  • 提取一致性(Consistently-extracted):合适的特征需要在源代码中和字节码中表示一致,例如:在smali中数组的创建是在具有可变长度参数的方法中声明的,但是源代码中没有这种表示。

使用下边的五个特征,constant values,method invocations, field accesses, object creation and special instruction types.

3.1.2 Feature Parser

对源代码和smali代码使用不同的parser。

Smali parser:使用dexlib来分析smali文件,smali中,首先将字都载入到虚拟寄存器中,然后再在smali指令中使用,因此无法直接从字中提取到需要的常数值,使用常量传播分析方法扫描整个方法建立表,存储所有虚拟寄存器中没有被改变的值,想要检查当前寄存器中是否存在常量时,从表中直接读取到常量值就可以。

Source code parser:在源代码中提取语义特征比smali中更加复杂,因为语法更加复杂,包含匿名内部类、嵌套类等。使用spoon来进行特征提取分析,通过遍历AST树来实现的对源代码的特征提取操作。

Literals Normalization:变量名在源代码中是以字符串形式存储,但是在smali代码中是常量。因此需要扫描全程序构建一个常量表格,通过分析表格来判断是否为常数值。

3.2 Line-to-line Match Engine

为了做行级的匹配分析,首先需要判断在smali代码中和原代码中存在多少匹配的结构。

s:从源代码中匹配到的特征集;b:从字节码中匹配到的特征集;使用Jaccard similarity [44]来定义两个集合之间的相似度。
$$
IsEquivalent(s,b) : JaccardSim(s,b) >= TLineSimilarity
$$
之前提过如果补丁的代码在函数中多次出现时,不适用与简单的线性匹配,因此对不同的情况会做不同的匹配算法。

3.2.1 When line number information is present

现有的java编译工具中都会保留行号信息,这个信息对于识别源代码和字节码之间的关系有很大帮助,但是BScout对于没有行号的情况也是可以匹配上关联信息的。

line Aggregation:行聚合。在smali中,行号信息如图中,会存在块的概念,拿到dex文件后,将其转换成smali代码表示,然后根据块进行划分,每一段进行单独的标识作为“行号”,然后构建源代码行和字节码行的匹配关系。

在块划分时遇到一些特殊情况:

  • 两个块具有相同的内容和行号:baksmali在try指令处理时,在每次return语句的位置都会加入一个相同的finally块,会对冗余的情况进行处理。
  • 两个不同的块存在相同的行号:因为编译器会将同一行的语句拆分成不同的块处理,比如,switch语句会拆分成两种块:以packed-switch/sparse-switch开头的smali结构块,和.switch开头的另一个块,这种情况我们会进行合并处理。

line-to-line match:行匹配。首先按照行号进行排序,方便匹配;然后设定三个规则去匹配。一、一行源代码只要需要匹配一到多行smali代码;二、源代码行号与smali行号不应该一致,smali行号应该比源代码行号数值要大;三、尽可能的匹配更多的源代码行对应smali行。 实际上可以理解为,行匹配等价于最长公共子序列,使用Myers algorithm[36,41]来进行匹配。进而可以判断补丁中的行在目标软件中是否存在。

3.2.2 When line number information is absent

当smali文件中缺失行号信息时,很难直接来判断每个块的边界,一个简单的方法就是从整个文件中进行行匹配算法,但是这会造成很低的效率与很高的误报。幸运的是我们发现专家经验对这类问题有很好的处理,对于字节码指令的分组与区分是可以找到规律的。首先将smali文件代码转换成段的方式,然后进行源代码对应段的匹配。

Learning-based Instruction Segmentation:基于学习的结构分割。我们想把smali文件用四种标签区分开:S(简单结构的段标识);B(段开始标识);M(段中间标识);E(段结尾标识)。训练集是从23个安卓rom和2064个maven包中提取的smali文件,使用定义的四种标识符进行标识,大概有1百万标识了的方法作为训练集,一千万个方法作为测试集,使用Conditional Random Fields(CRFs) [30]来进行训练模型,它是常用的序列标识上下文敏感的算法( context-sensitive algorithm for sequence labeling),使用 CRF++ [5],将cost参数设置为1,终止标识设置为0.0001来训练模型。模型的输入是smali结构,输出是他们带有的标识,使用这些标识可以很好的将他们划分为段。通过确认,对于测试集有91.7%的准确度。

Two-round Line-to-segment Match:两轮行2段匹配。首先使用公共最长子序列的方式进行一对一的匹配,但是不是所有的源代码都可以匹配上smali段,例如复合语句的存在。

使用下边的样例来说明如何处理复合语句:B就是A的复合语句的表现形式,将两行合并为一行代码。我们的段分割方式会将B处理成两个段,因此在匹配时会无法匹配A和B。

对于上述情况,使用第二轮的匹配。使用下图来说明:

这轮匹配从第一个没有匹配上的源代码行开始,会逐个的与第一轮没有匹配上的所有的smali段进行匹配,并会设置滑动窗口,每一句源代码都会对几段smali段进行合并匹配,匹配成功后进行下一次匹配,不成功会继续滑动窗口。

通过以上的方式,BScout可以成功的将java源代码和字节码一一对应,无论smali文件有没有提供行号信息,都可以成功的进行line-to-line识别。

3.3 Patch Analyzer

patch的信息,可以通过diff文件获取,如下图,diff文件中包含段开头@@,还有增加行与删除行的位置与内容。通过分析diff文件就可以很简单的拿到补丁的信息。

所有的补丁中修改的行都应该做补丁存在测试,我们将测试分成两类,一类是对方法内的行分析,另一类是方法外的行分析。大部分的java漏洞个都是逻辑问题,都需要对方法进行修复。经过我们的测试发现在194个真实安全补丁中,80%都是方法内的修复。因此我们认为方法外的修复可以被忽视。因此对于只有方法外修复的补丁BScout无法处理,但是我们分析发现不存在只有方法外的安全修复补丁,并且在补丁中还排除了注释的影响。

虽然所有的补丁都可以用增加行和删除行来表示,但是为了处理之前提到过得符合语句,如上图中的12与13行,增加的13行是对12行内容的修正,针对这种情况,采用启发式的方法来识别这种修改:将具有相似特征的相邻两行增加行和删除行作为复合行。

3.4 Patch Presence Checker

通过前述步骤可以识别出在目标软件中存在多少补丁中的行,进一步提供在目标上进行补丁存在测试的结果。

因为在补丁中存在多个多种类型,因此针对不同的类型进行不同的处理:对于增加的行去目标软件中匹配是否存在对应的字节码行;对于复合行,需要修复前文件和修复后文件的源代码进行比对。

算法一中展示了代码的主要逻辑:

首先拿到补丁前和补丁后源代码,然后与smali代码的对应关系Map;然后使用三种不同的策略分析(增加行、删除行、复合行)。

  • 增加行:找到对应的修复后的Map中smali代码,再与目标软件中进行匹配,找到就说明补丁存在
  • 删除行:找到对应的修复前的Map中smali代码,再与目标软件中进行匹配,没找到说明补丁存在
  • 复合行:与修复前和修复后的Map中smali代码,都与目标软件中代码计算相似度,修复前相似度高则说明补丁不存在

计算后,得到了每一行是否在存在,因为对于补丁中每个行对安全补丁的权重,因此将所有的行都进行计算,每行的权重相同,最后计算一个阈值来判断补丁是否存在。

Evaluation

BScout整体框架使用9290行java代码编写,具体上,使用SPOON作为分析java源代码的parser、dexlib来作为smali代码的parser、baksmali来将java应用程序转换成smali表示形式、对于传统的基于栈的java字节码,使用DX来将其转换成DEX字节码。

因为业内没有相同方向的工具,只有FIBER比较类似,但是FIBER是用于处理C/C++语言的,因此没有和其他工具的比对实验。其他的工作中也没有针对补丁存在分析问题的,因此文章的工作是唯一的。

4.1 Results of BScout

使用了两个版本的BScout:(为了说明没有行号信息的时候也可以处理)

  • BSCOUT:目标软件提供了行号信息的版本
  • BSCOUT△:目标软件中没有提供行号信息的版本

4.1.1 Android Framework Vulnerabilities

从Android Security Bulletin [2]中,选取150个CVE,时间跨度从2015年8月至2019年六月。下图为CVE的安卓版本分布表:

Parameter Setting:需要设置两个参数,一个是计算行相似度,另一个是根据行存在比例来计算补丁是否存在。为了测试这两个参数的选取,选取了一些目标认为的进行标注,然后根据实验的结果来确定参数选取。最后设置行相似度参数为0.7,补丁存在判断参数为0.6。

Ground Truth:下载了六个厂商的15个安卓rom,对于每一个rom都进行解包并人工的标注存在的CVE,由两位安全人员进行。

Results.:根据下图的结果表示,两个版本的BScout都表示了很好的效果,良好的实验结果充分的证明了,可以将源代码和字节码关联起来,并且可以识别出补丁中的细粒度差异。

存在的一些误报:构建源代码对应smali代码时的错误映射,分析发现,使用对控制流进一步分析的方法可以有效的规避误报,留给未来工作。

Efficiency of BSCOUT:时间开销上可以通过表二看到,时间开销很小,对于BScout来说定位到patch对应的函数并且判断是否存在很迅速。平均每个CVE的时间消耗是0.18s,一些时间开销高于平均的case,是由于补丁所在的函数本身很大,需要更多的时间来对应源代码与smali代码。BScout△分析CVE的时间在13.9s。

4.1.2 Java Library Vulnerablities

因为java第三方库的广泛性,因此也选择了第三方库进行实验。

Ground Truth.:从F-Droid上下载了4561个开源的app,通过对gradle文件的分析,识别了所有的第三方库,并找到这些库存在的CVE。随机的选取了11个库中的15个CVE作为实验目标。这些目标存在于261个app中。从中选取了12个服务端app和16个桌面应用作为测试目标。他们之中存在12个java第三方库收到29个CVE的影响。共计289个app作为app数据集。选取如下图:29+15 44个

Results.:只有五个误报,也都是因为源代码对应smali代码错误导致。

4.2 Results of Version Pinning

版本识别工具可以从几个可执行文件中识别最相似的某一个版本,现有的工具OSSPolice [21] and LibScout [17]可以用于识别补丁是否修复,因此在补丁识别上进行对比。修改现有的工具,将输出的结果人工标注补丁是否存在,由此作为工具的补丁识别结果。

Results.:由于两个工具分析目标可执行程序时粒度过大,无法区分补丁的微小差异;并且对于大规模的代码分析能力差。

4.3 Results of Function-level Similarity Test

函数相似度检测为了识别和漏洞相似的函数,也可以用于识别目标函数和补丁修复前的函数相似还是修复后的相似。

centroid [19]在安卓平台上广泛的用于识别函数间的相似度。

从数据集中收集471个和补丁相关的函数,并收集了函数修复前和修复后的函数代码,使用工具计算两个函数的相似度,相似度高于某值,则认为两个函数相似,如果是和补丁后的函数相似,则识别为已修复的版本。

根据上图的结果表明,大概82%的数据可以识别出补丁前后的差异,剩下的部分认为补丁前后的函数相似度相同。也是表明了从函数的粒度来分析补丁是否存在时有问题的。

5 Empirical Study

考虑进行进一步的测试,将BScout使用真实的项目进行大型测试,但是考虑到java的issue存在碎片化不存在统一的规范表示,这里选取从7个厂商手机的150个安卓框架CVE的2506个rom。将他们标注为表五中的Dataset_ROM_Large:

研究主要关注于三个方面:补丁应用程序的状态、安全补丁的滞后、安全补丁程序的管理

5.1 Patch Application Status

理论上,在任何的一个漏洞发布之后,所有的rom都应该立刻的对漏洞进行修复。因此我们将所有的ROM集合标识为Sall,将检测出来的不存在补丁修复的ROM集合标识为Sunpatched,对每一个CVE都会计算一个比值unpatched_ratio = Sunpatched / Sall。然后发现只有9个CVE是所有的ROM都已经修复漏洞的,22个CVE的没有补丁的版本比例超过50%。意味着,超过一半的ROM没有修复之前已经发布的漏洞。

RQ1:Does the severity of a vulnerability affect its patch application status:漏洞的危害程度是否会影响补丁应用程序的状态:

理想上来说,对于危害程度高的漏洞,厂商在修复漏洞时会更加关注。为了验证这一点,将每个CVE都找到他的CVSS分数。

如下图表示:发现危害度高的CVE并没有得到更高的修复率。两者并不存在直接的线性关系。

说明,开发者没有深刻的意识到漏洞的危害程度来进行对应的修复等级,或者漏洞的危害程度并不是开发者修复的主要参考指标。

RQ2: Does the complexity of a security patch affect its application ratio?:安全补丁的复杂程度是否会影响修复比例:

使用修复补丁的行号来表示补丁的复杂程度,结果表明并没有直接的关系。

如下图表示:

RQ3: Does code customization affect patch application:代码定制是都会影响补丁修复:

第三方库的开源代码,开发者在使用时会进行定制化。为了判断这个影响,引入了代码定制程度和补丁修复阈值的关系表示。

如下图表示:也没有直接的线性关系,但是总体上,代码定制化会影响对于补丁的修复。

综上发现:很多漏洞在发布了之后也没有进行及时的修复,并且发现漏洞的危害程度、补丁的复杂程度都不会影响开发者对漏洞的修复,但是定制化的代码会对于开发者修复有明显的障碍。

5.2 The Lag of Applying Security Patches

RQ4: What is the average lag for different vendors to apply a patch? :不同厂商对于补丁修复的平均延迟是多少?

推测方法:1、对于每个模型都收集10个镜像。2、对于每个镜像来检测CVE有没有被修复,并选择至少有一个镜像修复了的CVE。3、计算在漏洞出现的时间到第一个版本修复的时间间隔。

下图表示了对99个模型系统的补丁延迟时间:

综上发现:谷歌很多都是在漏洞公布之前进行修复,第三方厂商会补丁较慢,此外,统一厂商的不同手机型号补丁延时也有区别。

5.3 The Management of Security Patches

RQ5: Do vendors patch vulnerabilities for one model but ignore another?:厂商会不会只修复某一产品的漏洞,而对于另一个产品就忽略该漏洞?

检测方法:1、对于每一个CVE和厂商,选择第一个被修复的ROM作为First-ROM,2、然后去所有同样的CVE和厂商中找到没有被修复的ROM集合。3、找到属于同一厂商并存在其他ROM修复的ROM集合

如下图表示:发现几乎所有的厂商都存在将某一产品的cve修复但是忘记另外的产品修复同样的漏洞。

RQ6: Do vendors correctly set security patch level?:厂商是否合理的设置安全补丁的等级:

为所有的ROM都设置了在修复安全补丁时厂商标注的等级,并且也发现了233个ROM厂商没有设置安全补丁等级。

如下图表示:几乎所有的厂商都有忽略表示安全等级的情况,

Negligent ROMs(没有安全标识)Diligent ROMs(存在安全标识并修复了当前漏洞) Prudent ROMs(有安全标识并且修复了更高等级的漏洞)

综上发现:几乎所有的厂商包含谷歌在内都存在在修复安全补丁时忽略部分产品的情况,并且在修复安全补丁时低估安全补丁等级的情况也普遍存在。

5.4 Lessons Learned

开源软件上的漏洞没有被厂商及时的修补,总体来说很大一部分都没有打补丁,另一部分就算打了补丁也存在时间延迟,只有很少数是及时的进行了修复,并且在修复漏洞时厂商对于补丁的安全等级划分也不准确。我们认为存在这种情况是因为业内没有统一的透明的漏洞工具,准确的说明哪些软件中存在哪些漏洞需要修复。

另外,在进行漏洞修复时,厂商应该按照漏洞的危险等级以及复杂程度进行取舍,但是在实验中也没有发现这个现象,但是观察到,定制化的代码确实会影响厂商对于安全补丁的修复难易程度。说明需要更好的工具和方法来方便厂商进行漏洞的针对性修复。

6 Limitaions

在判断补丁存在测试时,忽略了out-of-method部分的补丁修改,因此对于补丁中只存在这类特征的时候没有办法进行处理。

使用CRFs的初始模型进行基于学习的代码信息识别。使用更新版本的模型。

无法区分补丁中行对漏洞的影响,没有赋值权重给不同的行。

需要提供准确的补丁文件与信息。

8 Conclusion

本文提出了BSCOUT,一种可以可靠、灵活、准确地测试Java可执行文件补丁是否存在的方法。

BSCOUT提出关键技术:利用基于特征的线级相似性测试,将Java源代码线链接到Java字节码指令,以及补丁细粒度的差异分析,通过计算目标可执行文件中确实包含多少补丁的修改行,给出了可靠和精确的补丁存在结果。

用安卓框架和第三方库的194个cve对BSCOUT进行了评估,结果表明BSCOUT既有效又高效。

通过BSCOUT,用2506个安卓rom对补丁应用实践进行了实证研究,这示了一些以前从未得到验证的有趣发现,并帮助社区进行更有效的努力来对修复漏洞。

sec20-dai.pdf (1.437 MB) 下载附件
点击收藏 | 0 关注 | 1
  • 动动手指,沙发就是你的了!
登录 后跟帖