一种用于ARM架构的软件漏洞辅助定位方法和系统

一种用于arm架构的软件漏洞辅助定位方法和系统
技术领域
1.本发明属于信息技术领域，更具体地，涉及一种用于arm架构的软件漏洞辅助定位方法和系统。


背景技术：

2.随着技术的发展，软件的规模和复杂程度都在不断增加，其中不可避免地存在各种各样的安全漏洞，导致程序的异常终止、崩溃。为了确认软件崩溃的根本原因，软件开发人员和安全分析师需要识别与崩溃相关的程序语句，分析这些语句，并最终找出软件漏洞的源头。目前的软件崩溃分析采用的方法主要是记录与重放技术和核心转储文件分析。
3.1.记录与重放技术技术人员经常依靠记录与重放技术来辅助追踪程序崩溃原因。记录与重放技术会实时记录程序运行时内存值与线程上下文内容的改变，程序崩溃后就可以利用之前记录得到的日志信息重放程序的崩溃过程，进而辅助技术人员分析诊断程序的漏洞。castor是一个有硬件支持的商用级的记录与重放工具，因为有硬件插桩机制，它的记录与重放过程的开销较低。ochiai和tarantula这两个工具通过重放记录正常的控制流和会导致线程崩溃的执行流来定位导致崩溃的关键指令。
4.2.核心转储文件分析核心转储文件是线程在接收到某些致命信号(deadlysignal)而终止运行时，由操作系统产生的记录此时线程地址空间的内容以及有关线程状态的其他信息的文件。一般而言，操作系统产生的核心转储文件可以用来分析程序等崩溃点与崩溃原因，进而为漏洞溯源与修复提供帮助。linux平台常用gdb代码调试工具来分析核心转出文件，windows平台的工具有windbg等。由于核心转储文件保存了程序崩溃前的上下文信息(包括寄存器值以及线程地址空间的状态)，它对与定位程序崩溃原因也起到了至关重要的作用。例如retracer与！analyze，其是完全基于核心转储文件的软件漏洞分析工具。一方面由于核心转储文件所携带信息的局限性，这两种工具也仅仅只有帮助分类软件崩溃报告的功能，另一方面正是因为它们完全基于核心转储文件做漏洞分析，使得这两种工具无法分析遇到类似缓冲区溢出攻击导致内存区域损坏严重的程序崩溃，因为遭到恶意篡改的内存区域会使得内存信息大量丢失，即核心转储文件本身的完整性会受到破坏。
5.综上所述，现有的崩溃后程序分析存在以下不足：对于记录重放技术，其会造成较大的时间开销，影响程序执行；对于基于核心转储的分析，其可与硬件追踪技术一同用于分析过程，但仍存在分析过程繁琐、耗时长等问题。目前，arm64架构上的现有技术无法对软件崩溃进行大规模的自动化漏洞诊断。


技术实现要素：

6.针对现有技术的缺陷，本发明的目的在于提供一种用于arm架构的软件漏洞辅助定位方法和系统，旨在解决现有技术无法对arm64架构上软件崩溃进行大规模的自动化漏洞诊断的问题。
7.为实现上述目的，第一方面，本发明提供了一种用于arm架构的软件漏洞辅助定位方法，该方法包括：
8.s1.运行待分析软件并触发漏洞使其崩溃，提取核心转储文件和崩溃前执行的指令序列，所述核心转储文件保存线程崩溃时的内存布局信息和寄存器信息；
9.s2.扫描核心转储文件，结合崩溃前执行的指令序列进行逆向执行，恢复出崩溃前每条指令内存地址信息和寄存器信息；
10.s3.从崩溃点出发，结合恢复出的信息，逆向追踪与崩溃点的数据有数据依赖关系的指令，得到直接或间接导致线程崩溃的指令序列。
11.优选地，步骤s1包括以下子步骤：
12.s11.通过etm设备采集待分析软件执行过程中的硬件追踪信息；
13.s12.通过操作系统层级的修改，在运行待分析软件时生成的核心转储文件中加入硬件追踪信息；
14.s13.对修改后的核心转储文件进行解析和提取，得到崩溃前执行的指令序列。
15.优选地，步骤s12具体如下：将提取到硬件最终信息转化为elf文件的load段，添加至核心转储文件最后一个load段的后面。
16.优选地，步骤s2具体如下：
17.s21.针对aarch64架构，为每条指令构造use节点与define节点，分别代表该指令对一个寄存器或者内存对象的读与写操作；
18.s22.将各个节点按控制流顺序以及对相同寄存器或内存对象的读写顺序相连，从而构造出一条use-define链；
19.s23.逆向遍历控制流的use-define链，补全每个节点中寄存器或内存对象的值及其内存地址。
20.优选地，步骤s23中，对于use节点，变量的值为读取该变量时，该变量的值；对于define节点，变量的值为被修改变量在修改后的值。
21.优选地，各个节点代表对象的值的推断遵循以下五条规则：
22.(1)该节点到use-define链尾之间的所有节点的变量都不是该节点的干预变量，从核心转储文件中读取该节点上的变量对应的值；
23.(2)该节点顺着指令流往前的第一个与该节点操作变量相同的use节点的变量值已知，认为该节点的变量值与此use节点的变量值一致；
24.(3)若该节点为define节点且其变量值已推断得知，则顺着指令流往前的第一个与其操作变量相同的use节点的变量值与其变量值一致；
25.(4)该节点为define节点且其变量值可通过指令语义推断出来；
26.(5)若该节点所在的指令为可逆指令，则通过所述可逆指令语义恢复得到该指令其他节点的变量值；
27.(6)该节点为define节点且其修改前的值已知，则逆着指令流往后的第一个与其操作变量相同的use节点的变量值与其变量值一致。
28.优选地，步骤s3具体为：逆use-define链追踪与崩溃点的数据有数据依赖关系的指令，标记这些指令为污点指令，追踪遵循以下规则：
29.1)若被污染的节点是define节点，则将污点传播给该define节点对应指令的其它
use节点的对象；
30.2)若被污染的节点是use节点，在没有干预变量干扰的情况下，将污点沿着控制流逆向传播给最近的操作变量相同的define节点；
31.3)根据相应指令语义，将污点传播给相应节点的对象；
32.4)若被污染的节点是内存访问节点，则将污点传播给参与地址运算的寄存器的use节点。
33.为实现上述目的，第二方面，本发明提供了一种用于arm架构的软件漏洞辅助定位系统，包括：包括处理器和存储器；
34.所述处理器用于存储计算机执行指令；
35.所述处理器用于执行所述计算机执行指令，使得第一方面所述的方法被执行。
36.总体而言，通过本发明所构思的以上技术方案与现有技术相比，具有以下有益效果：
37.本发明提出一种用于arm架构的软件漏洞辅助定位方法和系统，通过逆向执行和逆向污点分析，帮助广大软件开发者和安全分析人员快速定位导致线程崩溃程序的程序缺陷；通过将etm硬件记录的控制流数据置于核心转储文件内，有效地降低了用于崩溃程序分析的源数据的复杂度，简化了用户分析的流程；通过硬件辅助的追踪技术，减少软件缺陷调试中机器带来的额外开销，保证轻量化的同时准确诊断漏洞。
附图说明
38.图1为本发明提供的一种用于arm架构的软件漏洞辅助定位方法。
39.图2为本发明实施例提供的coresight系统数据流动图。
40.图3是本发明实施例提供的coresight追踪数据要素图。
41.图4是本发明实施例提供的崩溃后信息组成示意图。
具体实施方式
42.为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。
43.图1为本发明提供的一种用于arm架构的软件漏洞辅助定位方法。如图1所示，该方法包括：
44.步骤s1.运行待分析软件并触发漏洞使其崩溃，提取核心转储文件和崩溃前执行的指令序列，所述核心转储文件保存线程崩溃时的内存布局信息和寄存器信息。
45.优选地，步骤s1包括以下子步骤：
46.s11.通过etm设备采集待分析软件执行过程中的硬件追踪信息。
47.图2为本发明实施例提供的coresight系统数据流动图。如图2所示，oresight系统，主要有三个组件：
48.(1)追踪源(trace sources)：负责追踪的coresight组件，这些主要由依附在cortex core上的etm(embedded trace macrocells)设备构成，追踪在对应芯片上运行的程序的执行情况。每个cortex核心都有自己的etm。
49.(2)追踪基础架构(trace infrastructure)：追踪到的信息在传递过程中所需要的中间coresight组件，引导和复用源到汇之间的追踪信息。漏斗(funnel)负责将接收到多个etm设备上的追踪信息汇总到一起。此外该部分组件还可以控制追踪事件的启停。
50.(3)追踪汇(trace sinks)：最终接收追踪到的信息的组件，将追踪数据与追踪id联系起来，并将接收到的数据格式化为coresight框架的格式。它可以是芯片上的缓冲区(etb)，也可以是系统分配的缓冲区(etr)用来存储追踪到的数据。此外，还有一个tpiu组件(未在图中显示)，负责将追踪数据发送给外界。
51.采用coresight架构组件，可以通过硬件的方式获取程序的执行指令流。从系统架构图可以看出，追踪信息首先在依附在每个核心对应的etm设备上产生，经过基础架构的引导、复制，最终可以在etb/etr中获取指定追踪事件的追踪信息。
52.本发明的应用场景为具备etm硬件芯片的运行在arm架构下的以linux各发行版为操作系统的计算机。在etm芯片上工作的是由arm公司提出并研发的coresight架构。本发明首先通过操作系统提供的线程id，根据coresight系统提供的接口，从芯片的缓冲区中，获得被追踪的线程在计算机上所执行的指令的控制流，包括程序执行过程中所有分支指令的源地址和目的地址。coresight系统提供的控制流信息中除了最基本的指令的二进制编码，指令在内存中的地址，还包括追踪时每条指令的时间戳信息以及额外一些控制信息等。图3是本发明实施例提供的coresight追踪数据要素图。如图3所示，coresight设备中追踪数据的数据元素组成。其中包括追踪的地址及其值，时间戳等信息。在提取控制流的过程中，本发明只取所需要的时间戳信息和指令地址，指令二进制编码和线程id。
53.s12.通过操作系统层级的修改，在运行待分析软件时生成的核心转储文件中加入硬件追踪信息。
54.获得崩溃线程在崩溃前的指令控制流后，本发明将其整合进linux内核产生的有关该线程的核心转储文件中。图4是本发明实施例提供的崩溃后信息组成示意图。本发明根据这些如图4所示的崩溃后信息进行漏洞定位分析。
55.核心转储文件通常包括：程序崩溃时时的内存、寄存器状态、堆栈指针、内存映射信息、函数调用堆栈信息等内容，这些内容均为线程崩溃时linux内核所能保存的上下文信息。
56.核心转储文件本身是一个elf文件，包含：elf程序与文件头。其中，elf程序部分包括：elf程序头与程序内容。elf文件头包含：该文件的文件类型、文件格式等基础信息。elf程序中，程序头存有elf程序中各个段的入口地址信息，其中，包括note段与load段的入口。elf程序的note段存储有各类程序运行所需的状态信息，如：线程状态、cpu使用、线程id、各寄存器值等。其中，load段包含程序运行时的所用的内存信息。
57.优选地，步骤s12具体如下：将提取到硬件最终信息转化为elf文件的load段，添加至核心转储文件最后一个load段的后面。
58.s13.对修改后的核心转储文件进行解析和提取，得到崩溃前执行的指令序列。
59.步骤s2.扫描核心转储文件，结合崩溃前执行的指令序列进行逆向执行，恢复出崩溃前每条指令内存地址信息和寄存器信息。
60.由etm设备采集的控制流序列包含在程序运行过程中执行过的所有跳转指令，由于arm平台指令集定长，可借助跳转指令，根据崩溃时的内存状态，恢复出线程的完整控制
流序列。另外etm设备能够采集cpu多个核心的控制流信息，并对每控制流信息做了时间戳和线程id的记录，这使得本发明能够更好地处理有对同一内存区域进行访存的多线程程序的数据恢复工作。
61.优选地，步骤s2具体如下：
62.s21.针对aarch64架构，为每条指令构造use节点与define节点，分别代表该指令对一个寄存器或者内存对象的读与写操作。
63.节点可以视为一个结构体，包含这个节点的类型(use或者define)，节点代表的对象(寄存器或是一块内存，若是内存，则为内存地址)，对象所存的值。若是define节点还有一个指针数组，数组的各成员指向写操作中等号右边的各个对象。
64.s22.将各个节点按控制流顺序以及对相同寄存器或内存对象的读写顺序相连，从而构造出一条use-define链。
65.s23.逆向遍历控制流的use-define链，补全每个节点中寄存器或内存对象的值及其内存地址。
66.优选地，步骤s23中，对于use节点，变量的值为读取该变量时，该变量的值；对于define节点，变量的值为被修改变量在修改后的值。
67.优选地，各个节点代表对象的值的推断遵循以下五条规则：
68.(1)该节点到use-define链尾之间的所有节点的变量都不是该节点的干预变量，从核心转储文件中读取该节点上的变量对应的值；
69.(2)该节点顺着指令流往前的第一个与该节点操作变量相同的use节点的变量值已知，认为该节点的变量值与此use节点的变量值一致；
70.(3)若该节点为define节点且其变量值已推断得知，则顺着指令流往前的第一个与其操作变量相同的use节点的变量值与其变量值一致；
71.(4)该节点为define节点且其变量值可通过指令语义推断出来；
72.(5)若该节点所在的指令为可逆指令，则通过所述可逆指令语义恢复得到该指令其他节点的变量值；
73.(6)该节点为define节点且其修改前的值已知，则逆着指令流往后的第一个与其操作变量相同的use节点的变量值与其变量值一致。
74.另外，本发明使用假设性原则来解决逆向执行构造use-define链过程中可能遇到的内存别名问题。
75.内存别名是这样一个场景，由于一些不可逆指令的存在，use-define链在构造过程中不可避免地存在一些节点所代表的对象值不能得到恢复，这也导致一些取内存操作的内存地址值无法通过逆向执行过程得到。当涉及到需要对两个内存区域进行比较的场景时，如果其中存在未知的内存操作地址，其相对关系的判断将影响恢复的结果。而由于程序的执行状态已经确定，因此仅存在一种正确情况，如果从错误的相对关系判断出发则会导致后续的恢复产生冲突。
76.本发明采用假设性原则，即分别假设两个内存区域一致以及两个内存区域不一致的情况继续逆向执行，若在某种假设下，逆向执行过程中产生了约束冲突，如恢复出来的值与核心转储文件所存的不一致，假设性原则方案就可以否定掉它的假设，而采取另一个假设来恢复数据流。然而如果两种假设都不会产生约束冲突，这就说明了现在数据流并不能
为恢复当前指令的数据提供足够的信息。在这种情况下，将保留当前所采取的假设以恢复数据流，因为在接下来的数据恢复工作中，新的假设将提供产生更多的数据流信息，从而验证之前尚存疑的假设。
77.步骤s3.从崩溃点出发，结合恢复出的信息，逆向追踪与崩溃点的数据有数据依赖关系的指令，得到直接或间接导致线程崩溃的指令序列。
78.优选地，步骤s3具体为：逆use-define链追踪与崩溃点的数据有数据依赖关系的指令，标记这些指令为污点指令，追踪遵循以下规则：
79.1)若被污染的节点是define节点，则将污点传播给该define节点对应指令的其它use节点的对象；
80.2)若被污染的节点是use节点，在没有干预变量干扰的情况下，将污点沿着控制流逆向传播给最近的操作变量相同的define节点；
81.3)根据相应指令语义，将污点传播给相应节点的对象；
82.4)若被污染的节点是内存访问节点，则将污点传播给参与地址运算的寄存器的use节点。
83.得到直接或间接导致线程崩溃的指令集合后，用户可以对照源代码，标记出可能导致线程崩溃的语句及数据来源，更为轻松地定位出代码中的漏洞。
84.实施例
85.为了评估本发明对软件漏洞的自动化分析能力以及分析的执行效率，在dragonboard410c开发板上进行了更多的软件漏洞自动化分析测试实验。实验的步骤如下：
86.(1)通过nvd数据库中的信息在实验环境中复现该漏洞；
87.(2)人工分析确定崩溃的根本原因，找出导致崩溃的指令位置；
88.(3)运行漏洞poc，触发软件崩溃，获取带控制流信息的核心转储文件；
89.(4)使用本发明的发明分析该核心转储文件，根据(2)中比较后向污点分析是否能够定位到软件漏洞。
90.实验中，将分析程序的逆向执行指令最大数量设置为1000条。成功分析出崩溃原因的软件以及分析工具的运行时间如表1所示：
91.表1分析成功的软件列表
92.cve序号漏洞软件名称漏洞类型记录指令数量运行时间(s)cve-2004-12552fax-2.04stackoverflow1.60e 050.978cve-2004-1288o3read-0.0.3stackoverflow3.20e 051.047cve-2004-2167latex2rtf-1.9.15stackoverflow2.70e 061.519cve-2011-0420php-5.3.5nullpointer8.3e 0610.937cve-2016-7445openjpeg-2.1.1nullpointer2.20e 050.901
93.在性能方面，虽然arm平台的运行速度较慢，执行污点分析时可能需要一定的时间，但是在得到崩溃现场等相关信息之后，本发明可以在高性能的x86_64机器上运行，具有一定的跨平台性，能够为开发人员节约时间。
94.同时本发明还具有以下特色：
95.(1)首个基于arm平台硬件特性的自动化软件漏洞诊断工具：由于x86-64架构在个人主机与服务器平台的普及化，现存的大部分自动化软件漏洞诊断工具都是基于amd64架
构的，而无法迁移到arm架构使用。而本发明首发于arm平台，给面向于移动端设备和嵌入式设备、物联网设备的软件开发者带来了极大的便利。
96.(2)用户接口透明，适用于各种用户态程序场合：接口透明化，使软件崩溃分析工具的用户不必假设某一次运行软件会产生崩溃，本发明可以自动跟踪运行的程序，在其意外发生崩溃后收集崩溃后现场。并且本发明可以自动地跟踪随系统启动的后台守护线程的执行情况。本发明实现了将etm硬件记录的控制流数据置于核心转储文件内的方案，有效降低了用于崩溃程序分析的源数据的复杂度，简化了用户分析的流程。
97.(3)支持大多数常用aarch64结构指令的逆向解析，分析大多数用户态程序：逆向分析工作的一个环节就是解析指令，本发明完成了aarch64架构绝大多数常用指令，也即兼容了arm平台下绝大多数指令，使得本发明能用于分析诊断绝大多数用户态程序。
98.(4)支持多线程程序的分析：市面上为了提升用户体验而采取多线程技术提高软件性能的软件不在少数，大部分常用商业软件也都是多线程程序。本发明完成了对多线程程序的漏洞检测工作，使得本发明能够为市面上的大部分基于arm平台的软件提供漏洞诊断服务。
99.本领域的技术人员容易理解，以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。