Group of Software Security In Progress

Too Quiet in the Library an Empirical Study of Security Updates in Android Apps Native Code

作者:Sumaya Almanee1, Arda Unal1, Mathias Payer2, Joshua Garcia1

单位:University of California Irvine,EPFL

会议:ICSE 2021

论文链接:https://hexhive.epfl.ch/publications/files/21ICSE.pdf

Abstract

Android 应用程序一般包括第三方native库,以提高应用的性能和支持代码重用。Android开发者在他们的项目中添加了预编译的 native 库,通过本机的 Java 接口或 Android 开发工具包直接从应用程序执行。但是开发人员经常忽视及时更新这些库。这导致在补丁可用很久后仍继续使用存在未修补安全漏洞的第三方 native 库。

作者研究了2013年9月至2020年5月谷歌Play上最流行的200个免费应用程序的 native 库的安全更新。在这项研究中面临的一个核心困难是因为开发人员经常重命名或修改第三方库,所以其类型及版本的识别变得很困难。作者提出了一种名为 LibRARIAN 的第三方库的方法,基于相似度度量bin2sim,它可以准确地识别Android应用程序中的第三方库及其版本。LibRARIAN 根据库的元数据和在只读节中标识字符串,利用从库中提取的不同特性进行识别。2013年9月至2020年5月期间,作者发现有 53/200 个热门应用程序 (26.5%) 在补丁发布后存在已知 cve 的漏洞版本,其中14个仍然存在漏洞。作者还发现应用程序开发人员平均需要 528 天来应用安全补丁,而库开发人员平均在 library 发行 54 天后发布安全补丁,更新速度慢了10倍。

Introduce

第三方库方便、可重用,是移动应用程序不可分割的一部分。开发人员可以通过重用已经实现的功能来节省时间和精力。第三方native库在Android应用中非常普遍,尤其是社交网络和游戏应用。这两个应用类别在谷歌上名列前茅,需要特殊的功能,如3D渲染,或音频/视频编码/解码。这些任务往往是资源密集型的,因此通常由 native 库处理,以提高运行时性能。Android应用程序中第三方库的普遍存在增加了攻击面,因为主机应用程序暴露了从这些库传播的漏洞。之前的另一系列工作研究了Android应用程序中第三方Java 库的过时性和可更新性,重点关注此类应用程序的托管代码(如 Java 或 Dalvik 代码)。然而,这些先前的研究并没有考虑到Android应用程序使用的native库。作者认为native库中的安全影响更为关键。

  • 应用开发人员添加native库,但忽略了更新它们。这样做的原因可能包括对更新产生的改变的担忧、对功能稳定性的优先级高于安全性或者缺乏对库依赖关系及其安全补丁的跟踪。这种疏忽导致在新版本的应用程序中保留过时或易受攻击的native库
  • native库容易受到内存漏洞(例如缓冲区溢出攻击)的影响,这些漏洞很容易被利用
  • 第三方 native 库现在广泛应用于手机应用中。为了说明这一点,作者分析了2013年9月至2020年5月期间谷歌的前200名应用,总计7678个版本的200个热门免费应用程序。从这些应用中,总共确定了66,684个native库,平均每个应用有11个库。

为了更好地理解Android应用程序中第三方native库的使用及其安全影响,作者进行了一项纵向研究,以识别第三方native库的漏洞,并评估开发者更新其应用程序的此类库的程度。作者主要做出了以下研究贡献

  • 构建了一种叫做 LibRARIAN (第三方库版本识别) 的新方法,如果给定一个未知的二进制文件,它将识别出它实现的库以及对应的版本。
  • 进行了一项大规模的纵向研究,追踪应用程序中使用的 native 库的安全漏洞,收集了来自谷歌的200个最受欢迎的免费应用程序,建立了一个Android应用程序库和它们的native库,该存储库还包含这7678个不同应用的版本及其使用的66684个第三方native库。

LibRARIAN

上图显示 LibRARIAN 的整体工作流程。LibRARIAN 为了识别未知的第三方native库及其版本,方法是:

(1)提取出区分库的一些特性,这些特性无论在底层架构或编译环境中都是跨平台稳定的

(2)匹配从已知的库版本中提取的库版本信息的字符串

(3)使用新的相似度度量方法bin2sim将这些特征与已知库版本的ground-truth数据集的特征进行比较

Feature Vector Extraction

作者的二进制相似性检测是基于从二进制文件中提取特征,结合可执行文件和可链接格式文件中的元数据,以及识别库中不同二进制部分的特征。Android应用程序中包含的所有共享库都被编译成ELF二进制文件。与其他目标文件一样,ELF二进制文件包含一个 符号表 ,其中包含外部可见的标识符,如函数名、全局符号、局部符号和导入的符号。这个符号表被(1)在加载和链接过程中使用,(2)被二进制分析工具用来推断二进制数据的信息。

为了区分不同的库及其版本,该工具需要识别不同的特性。为此,作者定义了一组版本和库固有的六个特性。5个特征代表ELF元数据,这些特征用于计算描述的两个二进制文件之间的相似度评分,作者将这些特征称为元数据特征。此外利用从ELF对象的 .rodata 部分提取的字符串,作者将其称为版本标识字符串。该特征用于在相似度评分较低时的版本确认,同时作者也使用它来验证部分库版本的正确性。

上图显示了 LibRARIAN 选取的特性列表。这些特性包括:基于导出和导入函数、导出和导入全局函数和库依赖关系的5个 metadata 特性和 一个 data 特征。这6个特性代表了一个库的代码元素。不管底层体系结构或编译环境如何,这些特性在跨平台上都是稳定的,作者没有包括代码特性(例如,控制流和数据流特性),因为它们在编译和架构之间非常不稳定,会发生变化。作者指出二元相似性匹配是一个很难的问题,最近的工作在准确性方面取得了进展,但大多数算法的计算代价相对于代码大小是指数级的,不适合大规模的研究。

作者通过检查 ground-truth 数据集中的二进制数据建立了一个启发式数据集。作者开发了脚本来处理特性处理过程中提取的 .rodata 部分中的数据,并搜索包含版本信息的每个库的唯一字符串。

Similarity Computation

LibRARIAN 的相似度计算,作者称之为bin2sim。在计算应用程序二进制数据和 ground-truth 数据集之间的相似度分数时,利用了这五个元数据特征。bin2sim基于 Jaccard 系数,用来确定特征向量之间的相似度。bin2sim 允许 LibRARIAN 在不同的库和版本之间添加或删除特性,给定两个二进制文件 b1和b2,分别有特征向量FV1和FV2, bin2sim计算FV1和FV2的交集的大小(即共同特征的个数)除以FV1和FV2的并集的大小(即唯一特征的个数)。

如果一个未知的库实例的 bin2sim 值高于0.85,那么 LibRARIAN 将来未知库实例标记为与已知的库版本匹配。这个阈值是通过实验确定的,并且作者对其进行了评估。相似度较低可能是因为应用开发者对原始第三方库进行了修改,导致删除或添加特定功能。根据作者的调查,从原始程序库中移除功能在手机开发者中很常见,这可能是由于需要尽可能减少程序库和应用的大小。例如,作者发现 WebP 视频编解码器库部署时通常没有编码功能来减少二进制大小。一些大小优化技术需要从库中选择所需的模块,并保留其余部分,剥离生成的二进制文件,并修改构建标记。

Version Identification Strings

为了识别相似度较低的二进制文件,作者利用了版本识别字符串。例如,假设从应用程序 A 提取的库版本 B 与使用元数据特性的 OpenCV-2.4.11 的相似度评分为0.3。由于相似度评分低,作者在版本识别字符串中搜索特定的关键字,之前特征提取过程记录了来自 .rodata 部分的所有字符串(超过3个以0字节结尾的ASCII可打印字符的数组)以及其他特征。由于库通常有大量经常变化的只读字符串数据,我们不能直接使用这些数据作为特征(因为低重叠导致低相似度)。通过处理来自ground-truth数据集的 .rodata 并对数据进行聚类,作者提取了常见的版本标识符和版本字符串。然后,将它们翻译成正则表达式,使得能够匹配不同库的版本。

EVALUATION

Accuracy and Effectiveness

  • Comparative Analysis

作者将其工具与 OSSPolice 进行了比较。 OSSPolice 也是一个比较先进的库类型和版本识别的工具,其使用源代码构建索引,以识别二进制文件的版本。OSSPolice 衡量从二进制文件中提取的字符串与源存储库中直接找到的字符串特性之间的相似性。OSSPolice 评估中的 ground-truth 数据集包含从 F-Droid 收集的 104 个应用程序中提取的共475个二进制文件(其中67个是唯一的)。LibRARIAN 在OSSPolice数据集中正确识别 63/67 (94%) 的第三方库,与OSSPolice报告的正确识别 55/67 个(82%)相比,准确率提高了12%。OSSPolice的准确性较低,因为它依赖于简单的语法特性(例如字符串的值和导出函数),而作者的特征向量提取了额外的特性,如导入的函数、导出和导入的全局变量,以及唯一标识不同版本二进制文件的依赖关系。与OSSPolice相比,这些额外的功能是 LibRARIAN 准确性更高的主要因素。

  • Independent Accuracy

与OSSPolice的数据集相比,作者在更大、更近期的库版本集上进一步评估LibRARIAN的准确性。为此,作者手动收集一组具有已知库和版本的二进制文件,并将推断出来的库和版本与已知的库和版本进行比较,以确定 LibRARIAN 的准确性。作者基于常见Android应用程序中使用的库来构建了数据集。LibRARIAN 成功识别出了 824/904 (91.15%)个链接库。在该数据集中,共有 15.16% 包含精确的版本标志字符串。错误识别率为8.85%,这通常发生在连续版本的小或微修订(例如,3.1.0和3.1.1)。这些小的或微小的修订通常修复小的错误,不更改、添加或删除导出的符号。虽然在这种情况下,LibRARIAN不能精确地定位出确切的图书馆版本,但它显著地将后分析的搜索空间减少到几个候选版本。

  • Feature Effectiveness

Prevalence of Vulnerable Libraries

作者手动收集了 truth 数据集,由于手工分析非常耗时,作者对手工收集的库进行了限制:1.被超过10个 app 使用的库。2.曾经存在 cve 库。根据 LibRARIAN 的检测结果,在谷歌上排名前200的应用中,有53个 (26.5%) 在大约6年8个月的时间里 (即2013年9月至2020年5月) 曾受到漏洞库的影响。其中14款应用仍然存在漏洞,即在谷歌的前200款应用中,有7%的应用仍在运行。

Rate of Vulnerable Library Fixing