A Software Vulnerability Auxiliary Location Method and System for ARM Architecture

Abstract

The present invention discloses a method and system for assisting in locating software vulnerabilities for the ARM architecture, belonging to the field of information technology. It includes: running the software to be analyzed and triggering a vulnerability to cause it to crash, extracting the core dump file and the instruction sequence executed before the crash, where the core dump file stores the memory layout information and register information when the thread crashes; scanning the core dump file, performing reverse execution in combination with the instruction sequence executed before the crash, and restoring the memory address information and register information of each instruction before the crash; starting from the crash point, combining the restored information, and reverse-tracking the instructions that have a data dependency relationship with the data at the crash point to obtain the instruction sequence that directly or indirectly causes the thread to crash. The present invention helps software developers and security analysts quickly locate the program defects that cause the thread to crash; effectively reduces the complexity of the source data used for analyzing the crashed program, and simplifies the user analysis process.

Description

Technical Field

[0001] The present invention belongs to the field of information technology, and more specifically, relates to a method and system for assisting in locating software vulnerabilities for the ARM architecture. Background Art

[0002] With the development of technology, the scale and complexity of software are constantly increasing, and various security vulnerabilities inevitably exist, resulting in abnormal termination and crashes of programs. In order to confirm the root cause of software crashes, software developers and security analysts need to identify program statements related to the crashes, analyze these statements, and finally find the source of software vulnerabilities. Currently, the methods used for software crash analysis are mainly recording and replay technology and core dump file analysis.

[0003] 1. Recording and Replay Technology Technicians often rely on recording and replay technology to assist in tracing the cause of program crashes. The recording and replay technology will record in real time the changes in memory values and thread context content during program operation. After the program crashes, the log information obtained previously can be used to replay the crash process of the program, thereby assisting technicians in analyzing and diagnosing program vulnerabilities. Castor is a commercial-level recording and replay tool with hardware support. Due to its hardware instrumentation mechanism, the overhead of its recording and replay process is relatively low. The two tools Ochiai and Tarantula locate the critical instructions that cause crashes by replaying the recorded normal control flow and the execution flow that causes thread crashes.

[0004] 2. Core Dump File Analysis A core dump file is a file generated by the operating system when a thread terminates due to receiving certain deadly signals, recording the content of the thread's address space at this time and other information about the thread state. Generally speaking, the core dump file generated by the operating system can be used to analyze the crash points and causes of programs, etc., and thus provide help for vulnerability tracing and repair. The commonly used gdb code debugging tool in the Linux platform is used to analyze core dump files, and tools such as Windbg are available for the Windows platform. Since the core dump file saves the context information before the program crashes (including register values and the state of the thread address space), it also plays a crucial role in locating the cause of program crashes. For example, RETracer and!analyze are software vulnerability analysis tools that are completely based on core dump files. On the one hand, due to the limitations of the information carried by the core dump file, these two tools only have the function of helping to classify software crash reports. On the other hand, precisely because they perform vulnerability analysis completely based on core dump files, these two tools are unable to analyze program crashes caused by similar buffer overflow attacks that result in serious damage to memory areas, because the maliciously tampered memory areas will cause a large amount of memory information to be lost, that is, the integrity of the core dump file itself will be damaged.

[0005] In summary, the existing program analysis after crashes has the following deficiencies: For the record replay technology, it causes a large time overhead and affects program execution; for the analysis based on core dumps, it can be used in the analysis process together with the hardware tracing technology, but there are still problems such as cumbersome analysis process and long time consumption. Currently, the existing technologies on the ARM64 architecture cannot perform large-scale automated vulnerability diagnosis for software crashes. Summary of the Invention

[0006] Aiming at the deficiencies of the existing technologies, the purpose of the present invention is to provide a method and system for assisting in locating software vulnerabilities for the ARM architecture, aiming to solve the problem that the existing technologies cannot perform large-scale automated vulnerability diagnosis for software crashes on the ARM64 architecture.

[0007] To achieve the above purpose, in the first aspect, the present invention provides a method for assisting in locating software vulnerabilities for the ARM architecture, and the method includes:

[0008] S1. Run the software to be analyzed and trigger a vulnerability to cause it to crash, extract the core dump file and the instruction sequence executed before the crash, and the core dump file stores the memory layout information and register information when the thread crashes;

[0009] S2. Scan the core dump file, perform reverse execution in combination with the instruction sequence executed before the crash, and restore the memory address information and register information of each instruction before the crash;

[0010] S3. Starting from the crash point, in combination with the restored information, reverse-trace the instructions that have a data dependency relationship with the data at the crash point, and obtain the instruction sequence that directly or indirectly causes the thread to crash.

[0011] Preferably, step S1 includes the following sub-steps:

[0012] S11. Collect hardware tracing information during the execution of the software to be analyzed through an ETM device;

[0013] S12. Through modifications at the operating system level, add the hardware tracing information to the core dump file generated when running the software to be analyzed;

[0014] S13. Parse and extract the modified core dump file to obtain the instruction sequence executed before the crash.

[0015] Preferably, step S12 is specifically as follows: Convert the extracted final hardware information into the LOAD segment of the ELF file and add it to the back of the last LOAD segment of the core dump file.

[0016] Preferably, step S2 is specifically as follows:

[0017] S21. For the AARCH64 architecture, construct Use nodes and Define nodes for each instruction, representing the read and write operations of the instruction on a register or a memory object respectively;

[0018] S22. Connect each node in the order of the control flow and the read and write order of the same register or memory object, thereby constructing a Use-Define chain;

[0019] S23. Traverse the Use-Define chain of the control flow in reverse, and complete the values of the registers or memory objects and their memory addresses in each node.

[0020] Preferably, in step S23, for a Use node, the value of the variable is the value of the variable when reading the variable; for a Define node, the value of the variable is the value of the variable after modification.

[0021] Preferably, the inference of the values of the objects represented by each node follows the following five rules:

[0022] (1) For all nodes between this node and the end of the Use-Define chain, the variables are not the interfering variables of this node, and read the corresponding values of the variables on this node from the core dump file;

[0023] (2) If the variable value of the first Use node that operates on the same variable as this node and is forward along the instruction stream from this node is known, it is considered that the variable value of this node is the same as the variable value of this Use node;

[0024] (3) If this node is a Define node and its variable value has been inferred, then the variable value of the first Use node that operates on the same variable as it and is forward along the instruction stream is the same as its variable value;

[0025] (4) This node is a Define node and its variable value can be inferred through the instruction semantics;

[0026] (5) If the instruction where this node is located is a reversible instruction, then the variable values of other nodes of the instruction are restored through the reversible instruction semantics;

[0027] (6) This node is a Define node and its value before modification is known, then the variable value of the first Use node that operates on the same variable as it and is backward along the instruction stream is the same as its variable value.

[0028] Preferably, step S3 is specifically: Trace the instructions that have data dependencies with the data at the crash point in the reverse Use-Define chain, and mark these instructions as tainted instructions. The tracing follows the following rules:

[0029] 1) If the contaminated node is a Define node, propagate the taint to the objects of other Use nodes corresponding to the instruction of this Define node;

[0030] 2) If the contaminated node is a Use node, without the interference of intervention variables, propagate the taint backward along the control flow to the nearest Define node with the same operating variable;

[0031] 3) According to the semantics of the corresponding instruction, propagate the taint to the object of the corresponding node;

[0032] 4) If the contaminated node is a memory access node, propagate the taint to the Use node of the register participating in the address operation.

[0033] To achieve the above object, in a second aspect, the present invention provides a software vulnerability assisted location system for the ARM architecture, including: a processor and a memory;

[0034] The processor is used to store computer execution instructions;

[0035] The processor is used to execute the computer execution instructions, so that the method described in the first aspect is executed.

[0036] Generally speaking, compared with the prior art, the above technical solutions conceived by the present invention have the following beneficial effects:

[0037] The present invention proposes a software vulnerability assisted location method and system for the ARM architecture. Through reverse execution and reverse taint analysis, it helps software developers and security analysts quickly locate the program defects that cause thread crashes; by placing the control flow data recorded by the ETM hardware in the core dump file, it effectively reduces the complexity of the source data for crash program analysis and simplifies the user analysis process; through hardware-assisted tracing technology, it reduces the additional overhead brought by the machine in software defect debugging, ensures lightweight while accurately diagnosing vulnerabilities. Description of the Drawings

[0038] Figure 1 A software vulnerability assisted location method provided by the present invention.

[0039] Figure 2 A data flow diagram of the Coresight system provided by an embodiment of the present invention.

[0040] Figure 3 A Coresight trace data element diagram provided by an embodiment of the present invention.

[0041] Figure 4 A schematic diagram of the composition of information after a crash provided by an embodiment of the present invention. Detailed Implementation Manner

[0042] In order to make the objectives, technical solutions and advantages of the present invention more clear and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0043] Figure 1 A software vulnerability assisted location method for the ARM architecture provided by the present invention. As Figure 1 shown, this method includes:

[0044] Step S1. Run the software to be analyzed and trigger a vulnerability to cause it to crash, extract the core dump file and the instruction sequence executed before the crash. The core dump file stores the memory layout information and register information when the thread crashes.

[0045] Preferably, step S1 includes the following sub-steps:

[0046] S11. Collect hardware trace information during the execution of the software to be analyzed through an ETM device.

[0047] Figure 2 A data flow diagram of the Coresight system provided by an embodiment of the present invention. As Figure 2 shown, the Coresight system mainly has three components:

[0048] (1) Trace Sources: Coresight components responsible for tracing, which are mainly composed of ETM (Embedded Trace Macrocells) devices attached to the Cortex Core, and trace the execution of programs running on the corresponding chip. Each Cortex core has its own ETM.

[0049] (2) Trace Infrastructure: Intermediate Coresight components required for the traced information during transmission, guiding and multiplexing the traced information from the source to the sink. The funnel is responsible for aggregating the traced information received from multiple ETM devices together. In addition, the components in this part can also control the start and stop of trace events.

[0050] (3) Trace Sinks: Components that finally receive the traced information, associate the trace data with the trace ID, and format the received data into the format of the Coresight framework. It can be a buffer on the chip (ETB) or a buffer allocated by the system (ETR) to store the traced data. In addition, there is a TPIU component (not shown in the figure) responsible for sending the trace data to the outside world.

[0051] By using Coresight architecture components, the execution instruction stream of the program can be obtained in a hardware manner. As can be seen from the system architecture diagram, the trace information is first generated on the ETM device corresponding to each core, and after being guided and replicated by the infrastructure, the trace information of the specified trace event can finally be obtained in the ETB / ETR.

[0052] The application scenario of the present invention is a computer running on the ARM architecture with various Linux distributions as the operating system and equipped with an ETM hardware chip. The Coresight architecture proposed and developed by ARM Company works on the ETM chip. The present invention first obtains the control flow of the instructions executed by the traced thread on the computer from the buffer of the chip according to the interface provided by the Coresight system through the thread id provided by the operating system, including the source addresses and destination addresses of all branch instructions during the program execution process. In addition to the binary encoding of the most basic instructions, the address of the instruction in the memory, the control flow information provided by the Coresight system also includes the timestamp information of each instruction during tracing and some additional control information, etc. Figure 3 It is the Coresight trace data element diagram provided by the embodiment of the present invention. As Figure 3 shown, it is the composition of the data elements of the trace data in the Coresight device. It includes information such as the traced address and its value, and the timestamp. During the process of extracting the control flow, the present invention only takes the required timestamp information, instruction address, instruction binary encoding, and thread id.

[0053] S12. Through modifications at the operating system level, add hardware trace information to the core dump file generated when running the software to be analyzed.

[0054] After obtaining the instruction control flow of the crashed thread before the crash, the present invention integrates it into the core dump file related to this thread generated by the linux kernel. Figure 4 It is the schematic diagram of the composition of the information after the crash provided by the embodiment of the present invention. The present invention performs vulnerability location analysis based on the information after the crash as Figure 4 shown.

[0055] A core dump file usually includes: the memory, register status, stack pointer, memory mapping information, function call stack information, etc. at the time of program crash. All these contents are the context information that the Linux kernel can save when a thread crashes.

[0056] The core dump file itself is an ELF file, which contains: the ELF program and file header. Among them, the ELF program part includes: the ELF program header and program content. The ELF file header contains basic information such as the file type and file format of this file. In the ELF program, the program header stores the entry address information of each segment in the ELF program, including the entries of the NOTE segment and the LOAD segment. The NOTE segment of the ELF program stores various status information required for program operation, such as: thread status, CPU usage, thread ID, values of each register, etc. Among them, the LOAD segment contains the memory information used during program operation.

[0057] Preferably, step S12 is specifically as follows: Convert the extracted final hardware information into the LOAD segment of the ELF file and add it after the last LOAD segment of the core dump file.

[0058] S13. Parse and extract the modified core dump file to obtain the instruction sequence executed before the crash.

[0059] Step S2. Scan the core dump file and perform reverse execution in combination with the instruction sequence executed before the crash to restore the memory address information and register information of each instruction before the crash.

[0060] The control flow sequence collected by the ETM device contains all the jump instructions executed during the program operation. Since the ARM platform instruction set has a fixed length, the complete control flow sequence of the thread can be restored according to the memory state at the time of crash with the help of jump instructions. In addition, the ETM device can collect the control flow information of multiple cores of the CPU and record the timestamp and thread ID for each control flow information, which enables the present invention to better handle the data recovery work of multi-threaded programs that access the same memory area.

[0061] Preferably, step S2 is specifically as follows:

[0062] S21. For the AARCH64 architecture, construct Use nodes and Define nodes for each instruction, representing the read and write operations of the instruction on a register or a memory object respectively.

[0063] A node can be regarded as a structure, including the type of this node (Use or Define), the object represented by the node (register or a block of memory, if it is memory, it is the memory address), and the value stored in the object. If it is a Define node, there is also an array of pointers, and each member of the array points to each object on the right side of the equal sign in the write operation.

[0064] S22. Connect each node in the order of control flow and the read / write order of the same register or memory object, so as to construct a Use-Define chain.

[0065] S23. Traverse the Use-Define chain of the control flow in reverse, and complete the value of the register or memory object and its memory address in each node.

[0066] Preferably, in step S23, for a Use node, the value of the variable is the value of the variable when reading the variable; for a Define node, the value of the variable is the value of the modified variable after modification.

[0067] Preferably, the inference of the values of the objects represented by each node follows the following five rules:

[0068] (1) For all nodes between this node and the end of the Use-Define chain, the variables are not the interfering variables of this node, and read the corresponding value of the variable on this node from the core dump file;

[0069] (2) If the value of the variable of the first Use node that is the same as the operation variable of this node and is forward along the instruction stream from this node is known, it is considered that the value of the variable of this node is the same as the value of the variable of this Use node;

[0070] (3) If this node is a Define node and the value of its variable has been inferred, then the value of the variable of the first Use node that is the same as its operation variable and is forward along the instruction stream is the same as its variable value;

[0071] (4) This node is a Define node and the value of its variable can be inferred through instruction semantics;

[0072] (5) If the instruction where this node is located is a reversible instruction, then the variable values of other nodes of the instruction are restored through the reversible instruction semantics;

[0073] (6) This node is a Define node and the value before modification is known, then the value of the variable of the first Use node that is the same as its operation variable and is backward along the instruction stream is the same as its variable value.

[0074] In addition, the present invention uses the hypothetical principle to solve the memory alias problem that may be encountered in the process of constructing the Use-Define chain by reverse execution.

[0075] A memory alias is a scenario where, due to the existence of some irreversible instructions, there are inevitably some object values represented by nodes in the construction of the Use-Define chain that cannot be restored, which also leads to the inability to obtain the memory address values of some memory access operations through the reverse execution process. When it comes to scenarios that require comparing two memory regions, if there are unknown memory operation addresses among them, the judgment of their relative relationship will affect the restoration result. Since the execution state of the program has been determined, there is only one correct situation. If starting from the wrong relative relationship judgment, it will lead to conflicts in subsequent restoration.

[0076] The present invention adopts the hypothetical principle, that is, it continues to perform reverse execution by respectively assuming that the two memory regions are consistent and that the two memory regions are inconsistent. If, under a certain assumption, a constraint conflict occurs during the reverse execution process, such as the restored value being inconsistent with the value stored in the core dump file, the hypothetical principle solution can negate its assumption and adopt another assumption to restore the data stream. However, if neither of the two assumptions generates a constraint conflict, this indicates that the current data stream does not provide sufficient information to restore the data of the current instruction. In this case, the currently adopted assumption will be retained to restore the data stream because, in the subsequent data restoration work, new assumptions will provide more data stream information, thereby verifying the previously doubtful assumptions.

[0077] Step S3. Starting from the crash point, combined with the restored information, reverse-trace the instructions that have a data dependency relationship with the data at the crash point to obtain the instruction sequence that directly or indirectly causes the thread to crash.

[0078] Preferably, step S3 is specifically: reverse-trace the instructions that have a data dependency relationship with the data at the crash point along the Use-Define chain, and mark these instructions as tainted instructions. The tracing follows the following rules:

[0079] 1) If the contaminated node is a Define node, propagate the taint to the objects of other Use nodes of the instruction corresponding to this Define node;

[0080] 2) If the contaminated node is a Use node, without the interference of intervention variables, propagate the taint along the control flow in reverse to the nearest Define node with the same operating variable;

[0081] 3) According to the semantics of the corresponding instruction, propagate the taint to the objects of the corresponding nodes;

[0082] 4) If the contaminated node is a memory access node, propagate the taint to the Use nodes of the registers participating in the address operation.

[0083] After obtaining the instruction set that directly or indirectly causes the thread to crash, the user can compare it with the source code, mark the statements and data sources that may cause the thread to crash, and more easily locate the vulnerabilities in the code.

[0084] Embodiment

[0085] To evaluate the automated analysis ability of the present invention for software vulnerabilities and the execution efficiency of the analysis, more software vulnerability automated analysis test experiments were carried out on the Dragonboard410c development board. The steps of the experiment are as follows:

[0086] (1) Reproduce the vulnerability in the experimental environment through the information in the NVD database;

[0087] (2) Manually analyze to determine the root cause of the crash and find the instruction position that causes the crash;

[0088] (3) Run the vulnerability POC to trigger software crashes and obtain a core dump file with control flow information;

[0089] (4) Use the invention of the present invention to analyze the core dump file and determine whether the software vulnerability can be located according to the comparison of backward taint analysis in (2).

[0090] In the experiment, the maximum number of reverse execution instructions of the analysis program was set to 1000. The software that successfully analyzed the cause of the crash and the running time of the analysis tool are shown in Table 1:

[0091] Table 1 List of software with successful analysis

[0092] CVE Number Vulnerable Software Name Vulnerability Type Number of Recorded Instructions Running Time (s) CVE-2004-1255 2fax-2.04 Stackoverflow 1.60E+05 0.978 CVE-2004-1288 o3read-0.0.3 Stackoverflow 3.20E+05 1.047 CVE-2004-2167 latex2rtf-1.9.15 Stackoverflow 2.70E+06 1.519 CVE-2011-0420 php-5.3.5 Nullpointer 8.3E+06 10.937 CVE-2016-7445 openjpeg-2.1.1 Nullpointer 2.20E+05 0.901

[0093] In terms of performance, although the ARM platform runs slower and it may take some time to perform taint analysis, after obtaining relevant information such as the crash site, the present invention can run on a high-performance x86_64 machine, has a certain cross-platform nature, and can save time for developers.

[0094] At the same time, the present invention also has the following features:

[0095] (1) The first automated software vulnerability diagnosis tool based on the hardware characteristics of the ARM platform: Due to the popularization of the x86-64 architecture in personal host and server platforms, most existing automated software vulnerability diagnosis tools are based on the AMD64 architecture and cannot be migrated to the ARM architecture for use. The present invention was first launched on the ARM platform, bringing great convenience to software developers for mobile devices, embedded devices, and Internet of Things devices.

[0096] (2) The user interface is transparent and applicable to various user-mode program scenarios: The interface transparency enables users of the software crash analysis tool not to assume that a software run will crash. The present invention can automatically track the running program and collect the on-site situation after a crash occurs unexpectedly. Moreover, the present invention can automatically track the execution of background daemon threads started with the system. The present invention implements a solution to place the control flow data recorded by ETM hardware into the core dump file, effectively reducing the complexity of the source data for crash program analysis and simplifying the user analysis process.

[0097] (3) Support reverse parsing of most commonly used AARCH64 architecture instructions and analyze most user-mode programs: One link in the reverse analysis work is to parse instructions. The present invention has completed most commonly used instructions of the AARCH64 architecture, that is, it is compatible with most instructions under the ARM platform, enabling the present invention to be used for analyzing and diagnosing most user-mode programs.

[0098] (4) Support the analysis of multi-threaded programs: There are not a few software that adopt multi-threaded technology to improve software performance in order to enhance the user experience in the market, and most commonly used commercial software are multi-threaded programs. The present invention has completed the vulnerability detection work for multi-threaded programs, enabling the present invention to provide vulnerability diagnosis services for most software based on the ARM platform in the market.

[0099] (9) It is easy for those skilled in the art to understand that the above are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. A software vulnerability assisted location method for ARM architecture, characterized in that The method includes: S1. Run the software to be analyzed and trigger a vulnerability to cause it to crash, extract the core dump file and the instruction sequence executed before the crash. The core dump file stores the memory layout information and register information when the thread crashes; S2. Scan the core dump file, perform reverse execution in combination with the instruction sequence executed before the crash, and restore the memory address information and register information of each instruction before the crash; S3. Starting from the crash point, combine the restored information, and reverse-trace the instructions that have data dependencies with the data at the crash point to obtain the instruction sequence that directly or indirectly causes the thread to crash; Step S1 includes the following sub-steps: S11. Collect hardware trace information during the execution of the software to be analyzed through an ETM device; S12. Through modifications at the operating system level, add the hardware trace information to the core dump file generated when running the software to be analyzed; S13. Parse and extract the modified core dump file to obtain the instruction sequence executed before the crash; Step S2 is specifically as follows: S21. For the AARCH64 architecture, construct Use nodes and Define nodes for each instruction, representing the read and write operations of the instruction on a register or a memory object respectively; S22. Connect the respective nodes in the order of the control flow and the read and write order of the same register or memory object, thereby constructing a Use-Define chain; S23. Reverse-traverse the Use-Define chain of the control flow, and complete the values and memory addresses of the registers or memory objects in each node; Step S3 is specifically: Reverse-trace the instructions that have data dependencies with the data at the crash point along the Use-Define chain, and mark these instructions as tainted instructions. The tracing follows the following rules: 1) If the contaminated node is a Define node, spread the taint to the objects of other Use nodes corresponding to the instruction of this Define node; 2) If the contaminated node is a Use node, without the interference of intervention variables, spread the taint backward along the control flow to the nearest Define node with the same operating variable; 3) According to the semantics of the corresponding instruction, spread the taint to the objects of the corresponding node; 4) If the contaminated node is a memory access node, spread the taint to the Use nodes of the registers participating in the address operation.

2. The method according to claim 1, characterized in that, Step S12 is specifically as follows: Convert the extracted final hardware information into the LOAD segment of an ELF file, and add it after the last LOAD segment of the core dump file.

3. The method according to claim 1, wherein In step S23, for a Use node, the value of the variable is the value of the variable when the variable is read; for a Define node, the value of the variable is the value of the modified variable after modification.

4. The method according to claim 3, wherein The inference of the values of the objects represented by each node follows the following five rules: (1) None of the variables of all nodes between this node and the end of the Use-Define chain are the intervention variables of this node, and read the value corresponding to the variable on this node from the core dump file; (2) If the variable value of the first Use node with the same operating variable as this node along the instruction flow forward from this node is known, consider the variable value of this node to be the same as the variable value of this Use node; (3) If the node is a Define node and its variable value has been inferred, then the variable value of the first Use node that is the same as its operation variable and is forward along the instruction flow is the same as its variable value; (4) The node is a Define node and its variable value can be inferred through the instruction semantics; (5) If the instruction where the node is located is a reversible instruction, then the variable values of other nodes of the instruction are obtained by restoring through the reversible instruction semantics; (6) The node is a Define node and its value before modification is known, then the variable value of the first Use node that is the same as its operation variable and is backward along the instruction flow is the same as its variable value.

5. A software vulnerability assisted location system for the ARM architecture, characterized in that, including: including a processor and a memory; the processor is used to store computer execution instructions; the processor is used to execute the computer execution instructions, so that the method according to any one of claims 1 to 4 is executed.

Images