英语原文共 12 页，剩余内容已隐藏，支付完成后下载完整资料
了解Android系统漏洞：技术和见解
1.介绍
多年来，Android已经成为最受欢迎的普及设备系统，全球智能手机市场份额超过80%。随着越来越多的攻击针对Android，利用其应用程序和系统的漏洞[7,23,61,75]，检测和分析Android漏洞已经成为Android安全研究的一个新兴课题。与已被广泛研究的应用程序漏洞相比(如，[22, 24, 25, 27, 30, 34, 42, 48, 54, 58, 66-69, 72, 79, 80])，系统级的漏洞，然而，在文献中很少探讨(主要是关于框架层的漏洞，例如[16, 37, 60, 64])。这可能是由于难以理解低级的系统漏洞和缺乏分析资源造成的。
最近出现的漏洞奖励程序为研究人员提供了一个系统地分析漏洞的新来源。例如Finifter等人[29]对脆弱性奖励计划(VRP)进行了首次实证研究使用Chrome和Firefox VRPs，以及Zhao等人。[76]测量了白帽子在Hackerone和Wooyun漏洞平台上提交的漏洞报告。Android也有自己的漏洞奖励程序，称为Android安全公告程序。最近的一项研究[52]利用公告资源分析Android系统漏洞;然而，它仅依靠大量的手工工作来测量660个漏洞的元数据和统计结果。此外，只分析了来自相应CVE(常见漏洞和暴露)报告的文本信息，而没有挖掘补丁。
在这篇论文中，我们的目标是填补目前在理解Android系统漏洞方面的空白，我们进行了第一次系统研究，涵盖了所有的2179个漏洞和1349个公开可用的补丁，它于2015年8月启动，我们的分析于2018年6月启动。在未来为了使这种规模的研究和易于适应更大的数据集，至关重要的是采用一个系统的方法，手动工作只涉及配置分析和解释结果。幸运的是，使用结构化的公告报告，我们能够提出这样一个自动分析框架，它可以抓取、解析、清理和分析漏洞报告及其补丁。具体来说，它建立在一个层次化的数据库之上，将每个Android漏洞的所有文本和代码信息存储在一个有组织的、可搜索的结构中，其主要的新奇之处在于它的三个分析器，分别用于分析漏洞模块、补丁代码复杂性和漏洞模式。特别是如何从许多最初不相关的代码片段(即连续的代码行[40])是关键的挑战。我们现在详细阐述这三种分析仪以及相应的分析结果。
在第一个分析器中，我们根据不同的Android模块对漏洞进行了分类以揭示最易受影响的系统模块，从而需要更多的安全关注。与之前使用手动分析的工作[52]不同，我们提出了一种轻量级技术，它利用了Android Bulletin报告的两个有用特性(参见sect;3.2)针对给定的漏洞，有效的找出受影响的模块。利用该分析仪，我们成功地获得了Android漏洞模块的分层图，发现92%的Android漏洞位于底层模块中，这些底层模块主要使用C/ C 进行编码，尤其是本机库和内核驱动程序。相比之下，框架层和应用层仅占5%和2%。此外，与媒体、Wi-Fi和电话相关的模块在不同的层中引入了数百个漏洞，使它们具有很高的风险。我们还对存在大量漏洞的代码进行了更深入的研究，例如在libstagefright媒体库中出现了26个不同的补丁。
其次，我们提出了一个稳健的方法来研究补丁代码的复杂性，在这个方法中，我们提取“真正的”补丁差异代码，而不只是排除辅助代码行(如:包括/导入和注释语句)，以及与补丁相关联的测试代码。我们分析了从文件和代码行粒度提取的差异代码的复杂性。结果显示，很大一部分Android漏洞涉及非复杂的修复，其中60%只需要一个文件更改，50%的修复需要不到10行代码。这表明许多Android漏洞很可能是实现bug。
最后，我们提出了一个基于相似性的算法来自动聚类Android补丁代码模式，并揭示了系统开发人员常见的导致漏洞的编码错误。注意,这个任务是不同于经典的代码克隆检测问题[17,39,40,43,44,49-51,71]因为我们的目标是寻找类似的“变化”,涉及每对补丁包含四段代码,而代码克隆检测只关注两块每比较“原始”代码。为此，我们设计了一种针对相似补丁聚类的新算法。我们首先提取差异代码片段的基本更改，并将每个此类更改表示为一个代码文本。然后，我们通过计算这些代码文本的两两相似度来生成一个相似矩阵，并进一步利用亲和传播[31]来根据矩阵聚类自动生成。最后，模式是从集群中的顶部相似案例中抽象出来的。
通过运行这个算法，我们获得了83个初始集群，其中我们快速过滤掉了50个小型集群，因为它们每个只包含不到10个代码片段，并且实际上没有表现出明显的面向安全性的模式。在剩下的33个集群中，28个(84.8%)与某些模式相关，其中19个集群用于面向安全的模式，9个集群用于与安全无关的模式。我们最终从19个面向安全的集群中提取了16个漏洞模式。它们不仅包括传统的模式，例如:溢出和未初始化的数据，但也有6个新的文献中不知道的，如引用错误检索Android服务和不一致的Android 可打包序列化。然后我们通过案例分析来分析它们的特点。
此外，我们讨论了我们的分析结果的四个含义。除了定量指出Android系统漏洞的严重性和在未来的威胁模型中采用它们的必要性外，我们的结果可以帮助系统开发人员避免在同一个模块中犯类似的错误，并指导程序分析技术进行自动漏洞检测。
2 .ANDROID安全公告程序
(https://source.android.com/security/bulletin /)于2015年8月启动，每月更新一次。图1显示了其网站的示例页面(2016年10月)。它列出了在一个日历月内修复并公开的所有漏洞。如图1的右侧所示，它首先给出了不同模块(如服务管理器、锁设置服务和媒体服务器)中的漏洞的概要。对于每个模块，进一步列出详细的漏洞信息，包括CVE、Android漏洞ID (AID)、漏洞严重程度、更新的Android版本等。具体来说，AID的URL实际上是指向对应补丁代码的网页，我们称这种URL为“patch URL”。
3.方法
我们的目标是对Android系统的漏洞进行系统的研究，综合分析Android安全公告项目从2015年8月启动到2018年6月启动的所有漏洞。与之前的工作一样[41,52]尽量减少手动，我们提出了第一个能够自动抓取、解析、清理和分析Android公告报告及其公开可用补丁的分析框架。有了这样一个框架，仅在配置分析和解释结果(例如从自动生成的集群中提取模式)。它还可以很容易地适应更大的数据集在未来与演变的分析结果。
概述：图2显示了我们的分析框架的整体工作流程。它包括一个公告爬虫，一个补丁爬虫，一个清洁工，和三个分析仪。所有这些组件都是用Python编写的，包含1230行代码，不包括库支持，例如对硒[14]用于爬虫，水母[9]用于字符串相似度。我们将每个组件的功能总结为如下:
bull;公告爬虫负责抓取Android公告网站上每个漏洞的基本信息。抓取的信息包括CVE (Common Vulnerability Entry) id、漏洞类型、漏洞严重程度等元信息。一个重要的元信息是每个漏洞的补丁代码的url，补丁爬虫将进一步使用这些代码。所有这些信息都直接从公告网站的HTML文件中解析，并保存到漏洞元数据数据库中。
bull;Patch crawler将Patch url作为输入，抓取Patch code网站，然后构建一个Patch code数据库。由于针对Android公告漏洞的补丁代码网站有多种类型，我们构建了所有相应的补丁爬虫。这里的HTML解析比公告爬虫更复杂，因为将补丁的差异代码提取到有组织的结构中比较困难;详见sect;3.3。
bull;Cleaner用于清除原始数据库，特别是漏洞元数据中的文本信息。这是因为Android公告报告仍然是手动创建的，因此可能会出现混乱的文本。例如“EoP”漏洞类型可以表示为“特权提升-漏洞”、“elevation_of_privilege”，甚至“eopv”。此外，虽然大多数补丁的url是正确的，但也有一些是过时的(例如:“commit/ ?id= '而不是' patch/?id= ')，或包含未转义字符(例如“/”)和冗余字符(例如“la//”中的“/”多余)。Cleaner将一次性清除所有这些错误配置的信息。
bull;分析仪将清洗后的数据库作为输入和输出分析结果。除了漏洞元数据分析，我们还设计了三个分析器(如图2所示)来支持漏洞模块分析、补丁代码复杂度分析和补丁代码模式分析。我们将在后面的小节中对此进行说明。
挑战：由于我们是第一个以自动方式研究Android系统漏洞的，因此存在一些独特的挑战。值得注意的是，我们的三位分析人员分别面临着有效定位漏洞模块(sect;3.2)、稳健度量补丁代码复杂度(sect;3.3)和自动聚类漏洞模式(sect;3.4)的挑战。在详细解释这些挑战和我们克服这些挑战的方法之前，我们首先介绍sect;3.1 。我们如何将每个Android漏洞的所有文本和代码信息存储在一个有组织的、可搜索的结构中。
3.1设计层次数据库结构
第一个挑战是如何表示漏洞的文本和代码信息，以便分析人员能够直接进行SQL查询来检索所需的漏洞信息，而不需要编写额外的脚本。这是一个挑战，因为我们注意到1)一个Android漏洞可能与多个补丁有关;2)一个补丁可能包含多个受影响的代码文件;3)一个代码文件可能包含多个打过补丁的代码片段;4)一个代码片段通常包含几行代码。
我们建议构建一个分层的数据库结构，并使用精心设计的嵌套JSON[1]格式以分层的方式表示打过补丁的代码。图3显示了使用特定漏洞示例(CVE-2016-3900)的分层数据库结构的高层图。我们首先使用一个数据库表来记录这个漏洞的所有元数据，正如前面在公告爬虫组件中提到的那样。由于CVE-2016-3900涉及两个补丁，因此我们将两个补丁的信息保存在补丁代码数据库中，并将它们指向元数据数据库中相应的行id(本例中为1586)。最后，我们设计了一个嵌套的JSON格式来表示每个补丁的所有差异代码。通过这种方式，我们只使用一个数据库字段(图3中的“DiffCode”)来覆盖补丁代码，并避免动态扩展数据库。在每个JSON中，我们使用代码名作为JSON键，并使用嵌套数组来记录每个代码及其代码片段。图3显示了CVE-2016-3900的两个JSON示例，一个包含一个代码文件，另一个包含两个代码文件。这里所有的三部分都只列出了一个代码片段，但是在一个补丁代码中可能出现多个片段。
利用这种层次数据库结构，我们可以在SQL查询中直接对漏洞数据库进行复杂的搜索。清单1展示了一个查询示例，它计算每个补丁代码文件中代码片段的中位数。我们使用SQLite的JSON1扩展[10]来处理嵌套的JSON。例如，在清单1中，我们使用json_each() API将每个“DiffCode”字段分解为一个键-值行，其中键指的是代码文件名，而值是嵌套的代码片段数组。因此，我们可以使用key字段来排除汇编代码文件，并使用json_array_length(值)来进一步计数代码片段。通过这种方式，我们可以得到漏洞搜索结果(如在美国，如果不编写专用的脚本，每个文件的代码片段的中位数是2)。
Listing 1: A SQL query example of searching the database.
select median ( json_array_length ( value ) )
from PatchTable , json_each ( PatchTable . DiffCode )
where PatchTable . DiffCode like {%}
and key not like %. s;
3.2识别脆弱模块
根据不同的Android模块对漏洞进行分类，可以揭示出哪些系统模块最容易受到攻击，因此需要更多的安全关注。因此，我们在分析框架中包含了一个专用的分析器来识别易受攻击的Android模块。然而，这是具有挑战性的，因为在CVE报告中没有明确的模块信息。因此，之前的工作[52]雇佣了两个人来手动检查他们数据集中的660个Android漏洞。
我们提出了一种轻量级技术，它利用Android Bulletin报告的两个有用特性来定位给定漏洞的受影响模块。第一个是公开可用补丁的补丁代码路径，这可能意味着模块信息。然而，完整的代码路径通常过于详细，例如平台/系统/ bt / bta / dm / bta_dm_act.cc in CVE-2018- 9355。幸运的是，我们发现Android安全团队在补丁url中嵌入了高级模块路径信息。例如CVE-2018-9355的patch URL是https://android.googlesource.com/platform/system/bt/ /99a263，我们可以提取路径平台/系统/bt(即根据补丁代码网站[13]的蓝牙堆栈)作为受影响的模块。
由于我们的数据集中大约有一半的漏洞没有公开可用的补丁，我们仍然需要找到另一种方法来识别易受攻击的模块。此外，一些url的模块路径信息是粗粒度的，例如上述CVE- 2016-3900只显示平台/框架/本机在其补丁的URL。因此，我们的技术利用了第二个特性:Android Bulletin页面本身包含一定的模式，记录Android安全团队输入的模块信息。例如，在图1所示的公告页面中，我们可以找到CVE-2016- 3900的HTML字段lt;h3 id='eopv-in-servicemanager'gt;，其中'eopv '为漏洞类型，' servicemanager'为模块定位。
3.3 差异码的提取和计数
我们的第二个分析目标是研究Android补丁代码的复杂性，它需要一个健壮的方法来提取“真实的”补丁差异代码并计算它们的行变化。这是因为并不是所有修改后的代码行都是针对漏洞修复的，有些只是辅助的，例如 #include语句
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[410016]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
