Vulnerability detection method and device and electronic equipment

Abstract

The invention relates to the technical field of computer security, in particular to a vulnerability detection method and device and electronic equipment. The method comprises the following steps: reversely traversing a cross-language call graph from each dangerous node along call relationships, wherein the cross-language call graph comprises call relationships among different programming languages and call relationships among different codes in the same language environment. And recording a path through which the reverse traversal cross-language call graph passes, and constructing path libraries with different priorities based on a preset rule classification path. And obtaining seeds from the queues in sequence according to the priorities of the queues, and performing fuzzy testing on the seeds along the paths in the path library to obtain collapse information. Wherein the crash information comprises program data representing a crash reason, a crash position and the crash position. And determining security maintenance information related to the software vulnerability based on the crash information. According to the scheme, cross-language vulnerabilities can be detected, and the security of a software system is improved.

Description

Technical Field

[0001] The present application relates to the field of computer security technology, and in particular to a vulnerability detection method, device and electronic device. Background Art

[0002] With the iteration of cloud computing and technology, cross-language programming environments have become common. Java and C / C++ are the mainstream development languages, and vulnerability detection is essential. However, cross-language dynamic information flow analysis has limitations when dealing with complex data structures and scalability requirements.

[0003] How to detect cross-language vulnerabilities and improve the security of software systems has become a question worth discussing. Summary of the invention

[0004] The embodiments of the present application provide a vulnerability detection method, device, and electronic device for detecting cross-language vulnerabilities and improving the security of software systems.

[0005] In a first aspect, an embodiment of the present application provides a vulnerability detection method, the method comprising: traversing a cross-language call graph in reverse along a call relationship from each dangerous node, the cross-language call graph comprising call relationships between different programming languages ​​and call relationships between different codes in the same language environment, the dangerous node being a function node in the cross-language call graph that is marked as a potential security risk or a known vulnerability;

[0006] Record the path of reverse traversal of the cross-language call graph, and build a path library of different priorities based on preset rule classification paths. The path includes each code segment and call relationship traversed;

[0007] Seeds are obtained from the queues in order of priority, and the seeds are fuzzy tested along the paths in the path library to obtain crash information. Queues of different priorities are obtained based on the distance from the seeds in the initial seed library to the target dangerous node and whether they pass through cross-language nodes. The crash information includes the cause of the crash, the crash location, and program data related to the crash location;

[0008] Determine security maintenance information related to software vulnerabilities based on crash information.

[0009] Optionally, the above different programming languages ​​include Java code and C / C++ code, and the cross-language call graph is obtained in the following manner:

[0010] Use the Java bytecode analysis tool Soot to analyze Java code and build a Java call graph. Use the compiler LLVM tool to analyze C / C++ code and build a C / C++ call graph.

[0011] The JNI interface is used to connect the Java call graph and the C / C++ call graph to obtain a cross-language call graph.

[0012] Optionally, the above-mentioned classification of paths based on preset rules to build a path library with different priorities specifically includes:

[0013] During the reverse traversal, check whether the path contains a cross-language interface;

[0014] If the path contains a cross-language interface, store the path in a first-level path collection;

[0015] If the paths in the primary path set interact only through a single cross-language interface, store the paths in the secondary path set;

[0016] After the reverse traversal is completed, the remaining unclassified paths are stored in a three-level path collection.

[0017] Optionally, the queues of different priorities are obtained in the following manner:

[0018] Insert monitoring codes at basic blocks, dangerous nodes and cross-language interfaces of the cross-language call graph to obtain status information of seed execution in the path library with the lowest priority;

[0019] Calculate a first distance at the function level and a second distance at the basic block level from each seed to the target dangerous node based on the state information;

[0020] If the seed triggers the cross-language interface with the new path, and there is an improved path with the first distance or the second distance to the target dangerous node, the seed is stored in the first-level queue;

[0021] If the seed triggers the cross-language interface and the first distance or the second distance to the target dangerous node is not improved, the seed is stored in the second-layer queue;

[0022] If the seed has not been mutated and the cross-language interface has not been triggered, the seed is stored in the second-level queue;

[0023] If the seed has mutated and the cross-language interface has not been triggered, the seed is stored in the third-level queue.

[0024] Optionally, after each round of fuzz testing, the above method further includes:

[0025] Adjust the storage of seeds in queues of different priorities based on the historical status information of the seeds;

[0026] The seeds are modified according to the preset mutation rules, and the seeds are obtained from the adjusted queues in order of priority. The seeds are fuzz tested along the paths in the path library to obtain new crash information.

[0027] Optionally, modifying the seed according to a preset mutation rule specifically includes:

[0028] Based on the distance and coverage in the historical status information, the annealing algorithm is used to calculate the score of each seed. The seeds are sorted based on the score;

[0029] Select the mutated seeds based on the seed rating score.

[0030] In a second aspect, an embodiment of the present application provides a vulnerability detection device.

[0031] A processing module, configured to traverse a cross-language call graph in reverse order from each dangerous node along the call relationship, wherein the cross-language call graph includes call relationships between different programming languages ​​and call relationships between different codes in the same language environment, and wherein the dangerous node is a function node in the cross-language call graph that is marked as a potential security risk or a known vulnerability;

[0032] The processing module is further used to record the path of reverse traversal of the cross-language call graph, classify the paths based on preset rules to build a path library with different priorities, and the paths include each code segment and call relationship traversed;

[0033] A test module, used to obtain seeds from the queues in order according to the priority of the queues, and perform fuzzy testing on the seeds along the paths in the path library to obtain crash information. Queues of different priorities are obtained based on the distance from the seeds in the initial seed library to the target dangerous node and whether they pass through a cross-language node. The crash information includes the cause of the crash, the crash location, and program data related to the crash location.

[0034] The processing module is further configured to determine security maintenance information related to the software vulnerability based on the crash information.

[0035] In a third aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the processor implements any one of the vulnerability detection methods described in the first aspect.

[0036] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the vulnerability detection method of any one of the first aspects is implemented.

[0037] In a fifth aspect, an embodiment of the present application further provides a computer program product, including a computer program, which is executed by a processor to implement a vulnerability detection method as described in any one of the first aspects above.

[0038] The technical effects brought about by any one of the implementation methods in the second to fifth aspects can refer to the technical effects brought about by the corresponding implementation method in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 A schematic diagram of an application scenario of vulnerability detection provided in an embodiment of the present application;

[0040] Figure 2 A flow chart of a vulnerability detection method provided in an embodiment of the present application;

[0041] Figure 3 An exemplary flowchart of a vulnerability detection provided in an embodiment of the present application;

[0042] Figure 4 A schematic diagram of a vulnerability detection device provided in an embodiment of the present application;

[0043] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] Below, some terms in the embodiments of the present application are explained to facilitate understanding by those skilled in the art.

[0045] 1. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0046] 2. Basic Block: In the control flow graph, a basic block is a straight-line code sequence with only one entry point (the first statement) and one exit point (the last statement or jump statement).

[0047] 3. Critical Node: usually refers to the key points in the program that may cause errors or exceptions, such as memory access, file operations, network requests, etc.

[0048] 4. Inter-language Interface: refers to the interaction point between different programming languages, such as Java calling C / C++ library.

[0049] 5. Dynamic Instrumentation: Modify the behavior of a program while it is running, usually through an agent or runtime library.

[0050] 6. Static Instrumentation: Modify the source code or binary file of the program before or during compilation to insert monitoring code

[0051] 7. Fuzz testing is performed on software or systems. It is an automated software testing technique that aims to input a large number of invalid or unexpected test cases into the target program to trigger unexpected program behaviors, such as assertion failures, crashes, or hangs. These unexpected behaviors reveal vulnerabilities or defects in the program. In fuzz testing, "seed" refers to the original data or input used to generate test cases. These seeds are the basis of fuzz testing, and a large number of test cases can be generated by mutating and combining them.

[0052] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0053] The application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. It is known to those skilled in the art that with the emergence of new application scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems. In the description of the present application, unless otherwise specified, the meaning of "multiple" is two or more.

[0054] With the iteration of cloud computing and technology, cross-language programming environments have become common. Java and C / C++ are the mainstream development languages, and vulnerability detection is essential. However, cross-language dynamic information flow analysis has limitations when dealing with complex data structures and scalability requirements.

[0055] How to detect cross-language vulnerabilities and improve the security of software systems has become a question worth discussing.

[0056] In order to solve the above problems, an embodiment of the present application provides a vulnerability detection method. In this method, a cross-language call graph is traversed in reverse along the call relationship from each dangerous node. Among them, the cross-language call graph includes the call relationship between different programming languages ​​and the call relationship between different codes in the same language environment. The dangerous node is a function node marked as a potential security risk or a known vulnerability in the cross-language call graph. The path through which the cross-language call graph is traversed in reverse is recorded, and a path library of different priorities is constructed based on the preset rule classification path. The path includes each code segment and call relationship traversed. Seeds are obtained from the queue in sequence according to the priority of the queue, and the seeds are fuzzy tested along the path in the path library to obtain crash information. The queues of different priorities are obtained based on the distance from the seed of the initial seed library to the target dangerous node and whether it passes through the cross-language node. The crash information includes program data indicating the cause of the crash, the crash location, and the crash location. Determine the vulnerability type based on the crash information.

[0057] In this way, this application can capture potential cross-language vulnerabilities more comprehensively, especially those involving complex data structures and scalability requirements, by reversely traversing the cross-language call graph, compared to the prior art analysis of a single code language. The construction of the path library and the setting of priorities make fuzz testing more targeted, reducing unnecessary test times and waste of resources. The crash information obtained through fuzz testing can be further analyzed to provide strong support for subsequent vulnerability repairs and security protection. By automatically detecting vulnerabilities, manual intervention can be reduced and detection costs can be reduced.

[0058] A schematic diagram of an application scenario of an optional vulnerability detection method in an embodiment of the present application. Figure 1 As shown, it includes a server 100 and a terminal 101. The server 100 and the terminal 101 can be communicatively connected through a network to implement the vulnerability detection method of the present application.

[0059] The user can use the server 100 to interact with the terminal 101 through the network, such as receiving or sending messages, etc. Various client applications can be installed on the terminal 101, such as program writing applications, web browser applications, search applications, etc.

[0060] It is understandable that in the embodiment of the present application, the server 100 can be implemented as an independent server or a server cluster composed of multiple servers. The terminal 101 can be various electronic devices with a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, desktop computers, etc.

[0061] The server 100 can be used to reversely traverse the cross-language call graph along the call relationship from each dangerous node. Among them, the cross-language call graph includes the call relationship between different programming languages ​​and the call relationship between different codes in the same language environment. The dangerous node is a function node marked as a potential security risk or a known vulnerability in the cross-language call graph. The path of the reverse traversal of the cross-language call graph is recorded, and a path library of different priorities is constructed based on the preset rule classification path. The path includes each code segment and call relationship traversed. Seeds are obtained from the queue in sequence according to the priority of the queue, and the seeds are fuzz tested along the path in the path library to obtain crash information. Queues of different priorities are obtained based on the distance from the seed of the initial seed library to the target dangerous node and whether it passes through the cross-language node. The crash information includes the cause of the crash, the crash location, and program data related to the crash location.

[0062] like Figure 2 As shown, a flowchart of a vulnerability detection method provided in an embodiment of the present application may specifically include the following steps.

[0063] Step S201 , traverse the cross-language call graph in reverse order from each dangerous node along the call relationship.

[0064] The cross-language call graph includes the call relationships between different programming languages ​​and the call relationships between different codes in the same language environment. Dangerous nodes are function nodes marked as potential security risks or known vulnerabilities in the cross-language call graph.

[0065] The following describes how to build a cross-language call graph:

[0066] In an optional embodiment, the different programming languages ​​include Java code and C / C++ code. Java code can be analyzed by a Java bytecode analysis tool Soot to construct a Java call graph, and C / C++ code can be analyzed by a compiler LLVM tool to construct a C / C++ call graph. The Java call graph and the C / C++ call graph are connected using a JNI interface to obtain a cross-language call graph.

[0067] In this way, the interaction between Java and C / C++ codes can be clearly displayed through the cross-language call graph, which makes it easier to find potential errors and exceptions through the cross-language call graph, take timely measures to repair them, and reduce the risk of system crashes.

[0068] For example, a Java call graph and a control flow graph can be constructed based on the Soot tool. In the Java call graph, the call points for calling C / C++ code through the JNI interface are identified. A C / C++ call graph and a control flow graph are constructed based on the LLVM tool. In the C / C++ call graph, the call points for calling back Java code through the JNI interface are identified. According to the naming rules and registration information of JNI, a mapping relationship between Java methods and C / C++ functions is established. The Java call graph and the C / C++ call graph are merged into a cross-language call graph. Among them, the nodes in the cross-language call graph represent functions, and the edges represent function call relationships. For example, a node can be a Java method or a C / C++ function, and an edge can be a call relationship from Java to C / C++, a call relationship from C / C++ to Java, or a call relationship within the same language, such as a call relationship from Java to Java.

[0069] The following is an introduction on how to obtain dangerous nodes:

[0070] In an optional embodiment, a static analysis tool and a vulnerability database can be used to identify dangerous functions in C / C++ code. The function nodes marked in the cross-language call graph are used to obtain dangerous nodes so as to quickly identify dangerous functions. Among them, the dangerous function can be a dangerous function in a network preset by the user, or a dangerous function determined based on a historical vulnerability library. The dangerous node is a function node marked as a potential security risk or a known vulnerability in the cross-language call graph.

[0071] It is understandable that the hazard function can be adjusted according to the user's preset function and the historical hazard functions in the historical vulnerability library.

[0072] In this way, by marking the identified dangerous function nodes when building a cross-language call graph, dangerous nodes are formed to facilitate subsequent security analysis and vulnerability detection, thereby conducting targeted security testing and maintenance.

[0073] Step S202: Record the path of the reverse traversal of the cross-language call graph, and classify the paths based on preset rules to build a path library with different priorities.

[0074] The path includes each code segment and calling relationship traversed.

[0075] For example, the following preset rules can be used to classify paths and build path libraries of different priorities. During the reverse traversal process, check whether the path contains a cross-language interface (such as a JNI call interface, a COM interface, etc.). If the path contains a cross-language interface, store the path in a first-level path collection. If the paths in the first-level path collection only interact through a single cross-language interface, store the path in a second-level path collection. After the reverse traversal is completed, store the remaining unclassified paths in a third-level path collection.

[0076] In the above method, by storing the primary path, the secondary path, and the tertiary path in different data sets, it is convenient for subsequent data analysis. Different analysis strategies and methods can be adopted for data sets of different priorities, thereby improving the pertinence and efficiency of data analysis.

[0077] Optionally, after obtaining the first-level path set, the second-level path set and the third-level path set, it can be determined whether each path set includes a repeated path. If there is a repeated path, in order to ensure the uniqueness of the path, one repeated path can be retained and other repeated paths can be deleted.

[0078] Step S203: Obtain seeds from the queues in order according to the priorities of the queues, and perform fuzzy testing on the seeds along the paths in the path library to obtain crash information.

[0079] Among them, queues with different priorities are obtained based on the distance from the seed of the initial seed library to the target dangerous node and whether it passes through a cross-language node. The crash information includes the cause of the crash, the crash location, and program data related to the crash location.

[0080] In this way, by testing queues of different priorities layer by layer, it is possible to ensure that all parts of the system are fully tested, thereby enhancing the overall security of the system. Prioritizing the selection of seeds from high-priority queues for testing helps to quickly locate and discover potential security vulnerabilities.

[0081] For example, seeds may be selected from the first-layer queue for testing first. When the first-layer queue is empty, seeds in the second-layer queue are selected. If the second-layer queue is empty, seeds are selected from the third-layer queue. Crash information may include information such as the instruction address that caused the crash, source code location, register status, and memory-related information. Memory-related information may include information such as the layout of memory at the time of the crash, the value of a specific memory address, and stack traces.

[0082] Optionally, after the crash information is obtained, the crash information may be preprocessed and formatted for subsequent data analysis.

[0083] The following describes how to obtain queues of different priorities:

[0084] Insert monitoring code at the basic blocks, dangerous nodes and cross-language interfaces of the cross-language call graph to obtain the state information of seed execution. Based on the state information, calculate the first distance of each seed to the target dangerous node at the function level and the second distance at the basic block level. If the seed triggers the cross-language interface and the new path, and there is an improvement path for the first distance or the second distance to the target dangerous node, store the seed in the first-level queue. If the seed triggers the cross-language interface and the first distance or the second distance to the target dangerous node is not improved, store the seed in the second-level queue. If the seed has not been mutated and has not triggered the cross-language interface, store the seed in the second-level queue. If the seed has been mutated and has not triggered the cross-language interface, store the seed in the third-level queue.

[0085] In this way, by calculating the distance from each seed to the target dangerous node at the function level and the basic block level, it is possible to identify which seeds are more likely to trigger vulnerabilities. Storing seeds with closer distances in a queue with a higher priority allows these seeds to be tested first, thereby improving the efficiency of vulnerability detection. Storing seeds with farther distances in a queue with a lower priority can reduce unnecessary testing and avoid wasting time and resources. By calculating the distance at the function level and the basic block level, the degree of association between the seed and the target dangerous node can be measured more accurately.

[0086] For example, insert code at the basic blocks, dangerous nodes, and cross-language interfaces of the cross-language call graph. Among them, Java code is dynamically inserted, and C / C++ code is statically inserted. Insert monitoring code at the basic blocks, dangerous nodes, and cross-language interfaces of the cross-language call graph. Starting from the target dangerous node, use the breadth-first search algorithm to calculate the shortest path length from each function to the function where the target dangerous node is located, that is, the first distance. Starting from the basic block where the target dangerous node is located, use the breadth-first search algorithm to calculate the shortest path length from each basic block in each function to the basic block where the target point is located, that is, the second distance.

[0087] It is understandable that the seeds of the initial seed library in the first round of fuzz testing can be collected from data in the normal use of the software or system, such as user input, files, network packets, etc. It is also possible to use specific algorithms or tools to automatically generate seeds that conform to a specific format or structure. For example, for software that processes text data, a string that conforms to grammatical rules can be generated as a seed. It is also possible to obtain seeds from other reliable third-party data sources, such as open source projects, security databases, etc.

[0088] Optionally, after each round of fuzz testing, the seeds can be adjusted to be stored in queues of different priorities based on the historical status information of the seeds. The seeds are modified according to the preset mutation rules, and the seeds are obtained from the adjusted queues in order of priority, and the seeds are fuzz tested along the paths in the path library to obtain new crash information.

[0089] In this way, by adjusting the queue priority and test resource allocation, the fuzz testing process can be continuously improved to improve the accuracy and efficiency of vulnerability detection.

[0090] For example, monitoring code is inserted into the basic blocks, dangerous nodes, and cross-language interfaces of the cross-language call graph to obtain the historical status information of the seed execution. Based on the distance and coverage in the historical status information, the annealing algorithm is used to calculate the score of each seed. The seeds are sorted based on the score. The mutated seeds are selected based on the seed score. This facilitates the efficient selection of the next mutated seed based on the seed score in the next round of fuzz testing.

[0091] Optionally, since there are seeds that do not meet the cross-language characteristics in the first-layer queue, the second-layer queue, and the third-layer queue, that is, seeds that do not trigger cross-language interface calls or do not show cross-language characteristics. In order to make the seeds fully mutated and adapt to the test environment of the cross-language call graph, the seeds can be mutated based on the preset random mutation rules.

[0092] Among them, the random mutation rule can be a coarse-grained mutation or a fine-grained mutation, or a combination of coarse-grained mutation and fine-grained mutation strategies. Coarse-grained mutation refers to modifying code blocks or data structures, such as inserting or deleting code blocks, and modifying the size of data structures. Fine-grained mutation refers to local modification of code, such as changes to a single byte or instruction.

[0093] In this way, seeds with different characteristics can be generated by mutating seeds, triggering different code paths and conditions during the test process, thereby increasing the test coverage of the cross-language call graph and helping to discover more potential problems and vulnerabilities.

[0094] Step S204: Determine security maintenance information related to the software vulnerability based on the crash information.

[0095] For example, crash information is input into the big model to obtain security maintenance information, which may include crash repair suggestions, severity of vulnerabilities, and other information.

[0096] In this way, by determining security maintenance information related to software vulnerabilities based on crash information, vulnerabilities can be quickly located and software security and stability can be improved.

[0097] like Figure 3As shown, an exemplary flowchart of a vulnerability detection method provided in an embodiment of the present application may include the following steps:

[0098] Step S301, using the Java bytecode analysis tool Soot to analyze Java and construct a Java call graph, and using the compiler LLVM tool to analyze C / C++ code and construct a C / C++ call graph;

[0099] Step S302: Use the JNI interface to connect the Java call graph and the C / C++ call graph to obtain a cross-language call graph;

[0100] Step S303: traverse the cross-language call graph in reverse along the call relationship from each dangerous node, and record the path of the reverse traversal of the cross-language call graph;

[0101] Step S304: During the reverse traversal process, check whether the path contains a cross-language interface;

[0102] Step S305: If the path contains a cross-language interface, store the path in a first-level path set;

[0103] Step S306: If the paths in the primary path set interact only through a single cross-language interface, store the paths in the secondary path set;

[0104] Step S307: After the reverse traversal is completed, the remaining unclassified paths are stored in a third-level path set;

[0105] Step S308, classifying the distances from the seeds in the path library with the lowest priority in the fuzzy test to the target dangerous node to obtain queues of different priorities;

[0106] Step S309: obtaining seeds from the queues in order according to the priorities of the queues, and performing fuzzy testing on the seeds along the paths in the path library to obtain crash information;

[0107] Step S310: Determine security maintenance information related to the software vulnerability based on the crash information.

[0108] Figure 4 A schematic diagram of the structure of a vulnerability detection device provided in an embodiment of the present application. Figure 4 As shown, the device includes: a processing module 401 and a testing module 402.

[0109] Processing module 401, used to traverse the cross-language call graph in reverse along the call relationship from each dangerous node, the cross-language call graph includes the call relationship between different programming languages ​​and the call relationship between different codes in the same language environment, and the dangerous node is a function node marked as a potential security risk or a known vulnerability in the cross-language call graph;

[0110] The processing module 401 is also used to record the path of the reverse traversal of the cross-language call graph, and to classify the paths based on preset rules to build a path library with different priorities, wherein the path includes each code segment and call relationship traversed;

[0111] The test module 402 is used to obtain seeds from the queues in order of priority, and perform fuzzy testing on the seeds along the paths in the path library to obtain crash information. The queues with different priorities are obtained based on the distance from the seeds in the initial seed library to the target dangerous node and whether they pass through the cross-language node. The crash information includes the cause of the crash, the crash location, and program data related to the crash location;

[0112] The processing module 401 is further configured to determine security maintenance information related to the software vulnerability based on the crash information.

[0113] Optionally, the different programming languages ​​include Java code and C / C++ code, and the cross-language call graph is obtained in the following manner. The processing module 401 is further used for:

[0114] Use the Java bytecode analysis tool Soot to analyze Java code and build a Java call graph. Use the compiler LLVM tool to analyze C / C++ code and build a C / C++ call graph.

[0115] The JNI interface is used to connect the Java call graph and the C / C++ call graph to obtain a cross-language call graph.

[0116] Optionally, based on preset rule classification paths, a path library with different priorities is constructed, and the processing module 401 is specifically used for:

[0117] During the reverse traversal, check whether the path contains a cross-language interface;

[0118] If the path contains a cross-language interface, store the path in a first-level path collection;

[0119] If the paths in the primary path set interact only through a single cross-language interface, store the paths in the secondary path set;

[0120] After the reverse traversal is completed, the remaining unclassified paths are stored in a three-level path collection.

[0121] Optionally, queues of different priorities are obtained in the following manner, and the processing module 401 is further used for:

[0122] Use the Java bytecode analysis tool Soot to analyze Java and build a Java call graph. Use the compiler LLVM tool to analyze C / C++ code and build a C / C++ call graph.

[0123] The JNI interface is used to connect the Java call graph and the C / C++ call graph to obtain a cross-language call graph.

[0124] Optionally, based on preset rule classification paths, a path library with different priorities is constructed, and the processing module 401 is specifically used for:

[0125] During the reverse traversal, check whether the path contains a cross-language interface;

[0126] If the path contains a cross-language interface, store the path in a first-level path collection;

[0127] If the paths in the primary path set interact only through a single cross-language interface, store the paths in the secondary path set;

[0128] After the reverse traversal is completed, the remaining unclassified paths are stored in a three-level path collection.

[0129] Optionally, queues of different priorities are obtained in the following manner, and the processing module 401 is further used for:

[0130] Insert monitoring codes at basic blocks, dangerous nodes and cross-language interfaces of the cross-language call graph to obtain status information of seed execution in the path library with the lowest priority;

[0131] Calculate a first distance at the function level and a second distance at the basic block level from each seed to the target dangerous node based on the state information;

[0132] If the seed triggers the cross-language interface with the new path, and there is an improved path with the first distance or the second distance to the target dangerous node, the seed is stored in the first-level queue;

[0133] If the seed triggers the cross-language interface and the first distance or the second distance to the target dangerous node is not improved, the seed is stored in the second-layer queue;

[0134] If the seed has not been mutated and the cross-language interface has not been triggered, the seed is stored in the second-level queue;

[0135] If the seed has mutated and the cross-language interface has not been triggered, the seed is stored in the third-level queue.

[0136] Optionally, after each round of fuzz testing, the processing module 401 is further used to:

[0137] Adjust the storage of seeds in queues of different priorities based on the historical status information of the seeds;

[0138] The seeds are modified according to the preset mutation rules, and the seeds are obtained from the adjusted queues in order of priority. The seeds are fuzz tested along the paths in the path library to obtain new crash information.

[0139] Optionally, the seed is modified according to a preset mutation rule, and the processing module 401 is specifically used to:

[0140] Based on the distance and coverage in the historical status information, the annealing algorithm is used to calculate the score of each seed. The seeds are sorted based on the score;

[0141] Select the mutated seeds based on the seed rating score.

[0142] Based on the same technical concept, an electronic device is also provided in an embodiment of the present application, and the electronic device can realize the functions of the aforementioned vulnerability detection device.

[0143] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0144] At least one processor 501, and a memory 502 connected to the at least one processor 501. The specific connection medium between the processor 501 and the memory 502 is not limited in the embodiment of the present application. Figure 5 In the example, the processor 501 and the memory 502 are connected via a bus 500. The bus 500 is Figure 5 The connections between other components are shown in bold lines, and are not intended to be limiting. The bus 500 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 Only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. Alternatively, the processor 501 can also be called a controller, and there is no limitation on the name.

[0145] In the embodiment of the present application, the memory 502 stores instructions that can be executed by at least one processor 501. The at least one processor 501 can execute a vulnerability detection method discussed above by executing the instructions stored in the memory 502. The processor 501 can implement Figure 4 The functions of each module in the device shown.

[0146] Among them, the processor 501 is the control center of the device, and can use various interfaces and lines to connect the various parts of the entire control device. By running or executing instructions stored in the memory 502 and calling data stored in the memory 502, the various functions of the device and processing data, the device can be monitored as a whole.

[0147] In one possible design, the processor 501 may include one or more processing units, and the processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a driver interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the modem processor may not be integrated into the processor 501. In some embodiments, the processor 501 and the memory 502 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on separate chips.

[0148] Processor 501 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit, a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of a vulnerability detection method disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

[0149] The memory 502 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 502 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 502 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 502 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0150] By programming the processor 501, the code corresponding to the vulnerability detection method described in the above embodiment can be fixed into the chip, so that the chip can execute the code when running. Figure 2The embodiment shown is a vulnerability detection method. How to design and program the processor 501 is a technique known to those skilled in the art and will not be described in detail here.

[0151] It should be noted here that the above-mentioned electronic device provided in the embodiment of the present application can implement all the method steps implemented in the above-mentioned method embodiment, and can achieve the same technical effect. The parts and beneficial effects of this embodiment that are the same as the method embodiment will not be described in detail here.

[0152] An embodiment of the present application further provides a computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute a vulnerability detection method in the above embodiment.

[0153] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0154] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 Flow or flows and / or boxes Figure 1 A device that performs the functions specified in a box or multiple boxes.

[0155] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 Flow or flows and / or boxes Figure 1 The functions specified in one or more boxes.

[0156] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 Flow or flows and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0157] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A vulnerability detection method, characterized in that: The method comprises: Traversing the cross-language call graph in reverse order along the call relationship from each dangerous node, wherein the cross-language call graph includes the call relationship between different programming languages ​​and the call relationship between different codes in the same language environment, and the dangerous node is a function node in the cross-language call graph that is marked as a potential security risk or a known vulnerability; Recording the path of reverse traversal of the cross-language call graph, classifying the path based on preset rules to build a path library with different priorities, wherein the path includes each code segment and call relationship traversed; Obtaining seeds from the queues in order of priority, and performing fuzzy testing on the seeds along the paths in the path library to obtain crash information, wherein queues of different priorities are obtained based on the distance from the seeds in the initial seed library to the target dangerous node and whether they pass through a cross-language node, and the crash information includes indicating the cause of the crash, the crash location, and program data related to the crash location; Security maintenance information related to the software vulnerability is determined based on the crash information.

2. The method according to claim 1, characterized in that The different programming languages ​​include Java code and C / C++ code, and the cross-language call graph is obtained in the following manner: Use the Java bytecode analysis tool Soot to analyze Java code and build a Java call graph. Use the compiler LLVM tool to analyze C / C++ code and build a C / C++ call graph. The Java call graph and the C / C++ call graph are connected using a JNI interface to obtain the cross-language call graph.

3. The method according to claim 1, characterized in that The classifying the paths based on preset rules to build a path library with different priorities specifically includes: During the reverse traversal, checking whether the path contains a cross-language interface; If the path contains a cross-language interface, store the path in a first-level path set; If the paths in the primary path set interact only through a single cross-language interface, store the paths in the secondary path set; After the reverse traversal is completed, the remaining unclassified paths are stored in a three-level path collection.

4. The method according to claim 1, characterized in that: The queues of different priorities are obtained in the following manner: Insert monitoring codes at basic blocks, dangerous nodes and cross-language interfaces of the cross-language call graph to obtain status information of seed execution in the path library with the lowest priority; Calculate a first distance at the function level and a second distance at the basic block level from each seed to the target dangerous node based on the state information; If the seed triggers a cross-language interface and a new path, and there is an improved path to the first distance or the second distance of the target dangerous node, the seed is stored in a first-layer queue; If the seed triggers the cross-language interface and the first distance or the second distance to the target dangerous node is not improved, storing the seed in a second-layer queue; If the seed has not been mutated and the cross-language interface has not been triggered, storing the seed in a second-layer queue; If the seed has been mutated and the cross-language interface has not been triggered, the seed is stored in a third-layer queue.

5. The method according to any one of claims 1 to 4, characterized in that: After each round of fuzz testing, the method further includes: Adjusting the storage of the seeds in the queues of different priorities based on the historical status information of the seeds; The seeds are modified according to a preset mutation rule, the seeds are obtained from the adjusted queues in order according to the priorities of the queues, and the seeds are fuzzily tested along the paths in the path library to obtain new crash information.

6. The method according to claim 5, characterized in that The step of modifying the seed according to the preset mutation rule specifically includes: Based on the distance and coverage in the historical state information, an annealing algorithm is used to calculate the score of each seed, and the seeds are sorted based on the score; Select the mutated seeds based on the seed rating score.

7. A vulnerability detection device, characterized in that: The device comprises: A processing module, configured to traverse a cross-language call graph in reverse order from each dangerous node along the call relationship, wherein the cross-language call graph includes call relationships between different programming languages ​​and call relationships between different codes in the same language environment, and wherein the dangerous node is a function node in the cross-language call graph that is marked as a potential security risk or a known vulnerability; The processing module is further used to record the path of reverse traversal of the cross-language call graph, classify the paths based on preset rules to build a path library with different priorities, and the paths include each code segment and call relationship traversed; A test module, used to obtain seeds from the queues in order according to the priority of the queues, and perform fuzzy testing on the seeds along the paths in the path library to obtain crash information. Queues of different priorities are obtained based on the distance from the seeds in the initial seed library to the target dangerous node and whether they pass through a cross-language node. The crash information includes the cause of the crash, the crash location, and program data related to the crash location. The processing module is further configured to determine security maintenance information related to the software vulnerability based on the crash information.

8. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is used to cause the computer to execute the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that When the computer program product is called by a computer, the computer executes the method according to any one of claims 1 to 6.

Images