Third-party library file vulnerability detection method, device, electronic device and storage medium

Abstract

The present application discloses a third-party library file vulnerability detection method, device, electronic device and storage medium. The method includes: obtaining a third-party library file to be detected; comparing the third-party library file to be detected with a benchmark third-party library file to determine an incremental file; performing vulnerability detection on the incremental file to obtain incremental vulnerability information; updating the benchmark vulnerability information using the incremental vulnerability information to obtain the latest benchmark vulnerability information, wherein the benchmark vulnerability information is obtained based on the benchmark third-party library file detection. Through the above method, there is no need to perform full detection on the third-party library file to be detected, thereby improving the efficiency of vulnerability detection on the third-party library file to be detected.

Description

Technical Field

[0001] The present application relates to the technical field of vulnerability detection, and in particular to a method, device, electronic device and storage medium for detecting vulnerabilities in third-party library files. Background Art

[0002] With the continuous development of informatization, more and more applications will be used on different operating systems. For example, more and more applications with different functions are used on mobile terminals. In order to improve the development efficiency of applications and reduce the difficulty of code maintenance, the development of applications tends to introduce third-party library files to achieve modularization.

[0003] However, since third-party library files come from a wide range of sources and their versions are frequently updated, developers lack control over them, so security vulnerabilities are inevitable. Summary of the invention

[0004] The present application provides a third-party library file vulnerability detection method, device, electronic device and storage medium, which eliminates the need to perform full detection on the third-party library files to be detected, thereby improving the efficiency of vulnerability detection on the third-party library files to be detected.

[0005] In a first aspect, the present application provides a method for detecting vulnerabilities in third-party library files, the method comprising: obtaining a third-party library file to be detected; comparing the third-party library file to be detected with a benchmark third-party library file to determine an incremental file; performing vulnerability detection on the incremental file to obtain incremental vulnerability information; and updating the benchmark vulnerability information using the incremental vulnerability information to obtain the latest benchmark vulnerability information, wherein the benchmark vulnerability information is obtained based on the detection of the benchmark third-party library file.

[0006] In a second aspect, the present application provides a third-party library file vulnerability detection device, which includes: an acquisition module, used to obtain the third-party library file to be detected; a comparison module, used to compare the third-party library file to be detected with the benchmark third-party library file to determine the incremental file; a detection module, used to perform vulnerability detection on the incremental file to obtain incremental vulnerability information; an update module, used to update the benchmark vulnerability information using the incremental vulnerability information to obtain the latest benchmark vulnerability information, wherein the benchmark vulnerability information is obtained based on the benchmark third-party library file detection.

[0007] In a third aspect, the present application provides an electronic device, comprising a processor and a memory coupled to the processor; wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the method provided in the first aspect.

[0008] In a fourth aspect, the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the method provided in the first aspect.

[0009] The beneficial effects of the present application are as follows: Different from the prior art, the present application provides a third-party library file vulnerability detection method, device, electronic device and storage medium. The method compares the third-party library file to be detected with the benchmark third-party library file to determine the incremental file, which can reduce the size of the files involved in the subsequent vulnerability detection, and can perform vulnerability detection on the incremental file, quickly obtain incremental vulnerability information, and then use the incremental vulnerability information to update the benchmark vulnerability information, without the need to perform full detection on the third-party library file to be detected, thereby improving the efficiency of vulnerability detection on the third-party library file to be detected. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work. Among them:

[0011] Figure 1 This is a flow chart of the first embodiment of the third-party library file vulnerability detection method provided by the present application;

[0012] Figure 2 It is a flowchart of the second embodiment of the third-party library file vulnerability detection method provided by the present application;

[0013] Figure 3 It is a flowchart of an embodiment of step 23 provided by the present application;

[0014] Figure 4 It is a flowchart of an embodiment of step 24 provided by the present application;

[0015] Figure 5 It is a flowchart of an embodiment of step 43 provided by the present application;

[0016] Figure 6 It is a flowchart of a third embodiment of the third-party library file vulnerability detection method provided by the present application;

[0017] Figure 7 and Figure 8 This is a schematic diagram of an application scenario of a third-party library file vulnerability detection method provided by this application;

[0018] Fig. 9 It is a schematic diagram comparing the third-party library file vulnerability detection method provided by this application with related solutions;

[0019] Fig.10 It is a structural diagram of an embodiment of a third-party library file vulnerability detection device provided by the present application;

[0020] Fig.11 It is a structural schematic diagram of an embodiment of an electronic device provided by the present application;

[0021] Fig.12 is a structural schematic diagram of another embodiment of the electronic device provided by the present application;

[0022] Fig.13 It is a structural schematic diagram of an embodiment of a computer-readable storage medium provided by the present application. DETAILED DESCRIPTION

[0023] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It will be understood that the specific embodiments described herein are only used to explain the present application, rather than to limit the present application. It should also be noted that, for ease of description, only some but not all structures related to the present application are shown in the drawings. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0024] Reference to "embodiments" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0025] The following explanations are given for the professional terms, abbreviations, and custom words that appear in this application:

[0026] Third-party library: A code library provided by a third party that software developers reference in order to introduce a certain functional module or development tool.

[0027] JAR: JAR file is a software package file format, commonly used to aggregate a large number of compiled Java class files, related metadata and resource files into one file for the development of Java platform application software or libraries.

[0028] AAR: AAR file is a binary archive file of an Android library project, which generally contains library files, resource files, AndroidManifest files and classes.jar.

[0029] AndroidManifest: The manifest file of an Android application, including important configuration information such as program components, permissions, and application name.

[0030] Static taint analysis: Static taint analysis is to analyze whether the data introduced by the taint source in the static code can be directly transmitted to the taint aggregation point without harmless processing. If not, it means that the system is information flow secure; otherwise, it means that the system has security issues such as privacy data leakage or dangerous data operation.

[0031] Control Flow Graph (CFG): A control flow graph is an abstract representation of a process or program, often expressed in the form of a data structure chain. It is a simplified version of a program flow chart, and it can more prominently represent the structure of the program control flow.

[0032] Interprocedural Control Flow Graph (ICFG): ICFG is composed of the CFG of each method in the program and the calling relationship between methods.

[0033] See also Figure 1 , Figure 1 : is a flow chart of a first embodiment of a third-party library file vulnerability detection method provided by the present application, the method comprising:

[0034] Step 11: Get the third-party library file to be tested.

[0035] In some embodiments, the third-party library file may be a third-party library file based on an Android system. The third-party library file may be a third-party library file based on a Windows system. The third-party library file may be a third-party library file based on an IOS system.

[0036] Step 12: Compare the third-party library file to be detected with the benchmark third-party library file to determine the incremental file.

[0037] In some embodiments, the benchmark third-party library file may be obtained based on the first third-party library file.

[0038] In an application scenario, different developers have developed several third-party library files, such as third-party library file A, third-party library file B, third-party library file C, third-party library file D, and third-party library file E. Vulnerability detection can be performed on third-party library file A to obtain vulnerability information corresponding to third-party library file A. At this time, third-party library file A can be used as a benchmark third-party library file, and the vulnerability information corresponding to third-party library file A can be used as the benchmark vulnerability information. The remaining third-party library files B, third-party library files C, third-party library files D, and third-party library files E are sequentially subjected to vulnerability detection according to the method of this embodiment.

[0039] That is, the third-party library file B is compared with the third-party library file A to determine the incremental file b. The third-party library file C is compared with the third-party library file A to determine the incremental file c. The third-party library file D is compared with the third-party library file A to determine the incremental file d. The third-party library file E is compared with the third-party library file A to determine the incremental file e.

[0040] The incremental file may be a file newly added to the third-party library file to be detected when the third-party library file to be detected is compared with the benchmark third-party library file, that is, a file not included in the benchmark third-party library file.

[0041] The incremental file may be a file deleted from the third-party library file to be detected when the third-party library file to be detected is compared with the benchmark third-party library file, that is, a file that exists in the benchmark third-party library file but does not exist in the third-party library file to be detected.

[0042] The incremental file can be a file that has been modified in the third-party library file to be detected when the third-party library file to be detected is compared with the benchmark third-party library file, that is, the file exists in the benchmark third-party library file, but has changed in the third-party library file to be detected, such as being modified.

[0043] Based on this, the incremental file can be a file determined by any of the above comparison methods.

[0044] Step 13: Perform vulnerability detection on the incremental file to obtain incremental vulnerability information.

[0045] Vulnerability detection can be divided into detection of known vulnerabilities and detection of unknown vulnerabilities. Detection of known vulnerabilities mainly uses security scanning technology to detect whether incremental files have published security vulnerabilities; while the purpose of unknown vulnerability detection is to discover vulnerabilities that may exist in incremental files but have not yet been discovered.

[0046] For example, at least one method such as security scanning, source code scanning, disassembly scanning, and environmental error injection may be used to perform vulnerability detection to obtain incremental vulnerability information.

[0047] Among them, security scanning is also called vulnerability assessment. Its basic principle is to simulate hacker attacks to detect known security vulnerabilities that may exist in the target one by one.

[0048] Among them, source code scanning is mainly aimed at open source programs, and by checking the file structure, naming rules, functions, stack pointers, etc. in the program that do not comply with security rules, it can discover potential security defects in the program. This vulnerability analysis technology requires proficiency in programming languages, and pre-defined review rules for unsafe codes, and checks the source code through expression matching methods.

[0049] Among them, disassembly scanning is often the most effective way to discover security vulnerabilities for programs whose source code is not open. Analyzing disassembled code requires extensive experience, and auxiliary tools can be used to help simplify the process, but it is impossible to have a fully automatic tool to complete the process. For example, using an excellent disassembler tool, you can get the assembly script language of the target program, and then scan the assembled script language to identify some suspicious assembly code sequences.

[0050] Among them, environmental error injection is to deliberately inject artificial errors into the environment in which the software runs and verify the reaction. During the test process, the error is injected into the environment, so interference is generated. In other words, during the test process, the environment in which the software runs is disturbed to observe how the program reacts under such interference and whether a security incident will occur. If not, the system can be considered safe. In short, the error injection method is to try to trigger the security vulnerabilities contained in the program by selecting an appropriate error model.

[0051] In this embodiment, vulnerability detection can detect collusion between third-party library files, XXE vulnerabilities, unauthorized vulnerabilities, etc.

[0052] Step 14: Use the incremental vulnerability information to update the baseline vulnerability information to obtain the latest baseline vulnerability information, wherein the baseline vulnerability information is obtained based on the detection of the baseline third-party library file.

[0053] The benchmark vulnerability information is obtained by performing vulnerability detection on the benchmark third-party library files.

[0054] In some embodiments, after the incremental vulnerability information is obtained, the incremental vulnerability information can be used to update the baseline vulnerability information. For example, because the incremental vulnerability information is generated based on the incremental file. The incremental file can be a newly added file in the third-party library file to be detected, a modified file in the third-party library file to be detected, and a file deleted in the third-party library file to be detected. Therefore, when updating the baseline vulnerability information, the incremental vulnerability information of the newly added file corresponding to the third-party library file to be detected can be directly added to the baseline vulnerability information, and the incremental vulnerability information of the modified file corresponding to the third-party library file to be detected can replace the vulnerability information of the modified file in the baseline vulnerability information. The incremental vulnerability information of the deleted file corresponding to the third-party library file to be detected can continue to be retained in the baseline vulnerability information.

[0055] In an application scenario, the method of the above embodiment can be used to perform batch vulnerability detection on multiple third-party library files to be detected. After detecting one third-party library file to be detected and updating the baseline vulnerability information, the next third-party library file to be detected is detected again, and the baseline vulnerability information is updated. In this cycle, multiple third-party library files to be detected are detected and the latest baseline vulnerability information is obtained.

[0056] In this embodiment, the third-party library file to be detected is compared with the baseline third-party library file to determine the incremental file, which can reduce the size of the files involved in subsequent vulnerability detection, and can perform vulnerability detection on the incremental file to quickly obtain incremental vulnerability information, and then use the incremental vulnerability information to update the baseline vulnerability information. There is no need to perform full detection on the third-party library file to be detected, thereby improving the efficiency of vulnerability detection on the third-party library file to be detected.

[0057] And when performing vulnerability detection on multiple versions of third-party library files to be detected, the above method is used to determine the incremental files for each third-party library file to be detected, thereby reducing the size of files subsequently involved in vulnerability detection, and being able to perform vulnerability detection on incremental files, quickly obtain incremental vulnerability information, and then use the incremental vulnerability information to update baseline vulnerability information. This can solve the problem of redundant workload when batch processing multiple versions of third-party library files to be detected, and improve the efficiency of vulnerability detection on multiple versions of third-party library files to be detected.

[0058] See also Figure 2 , Figure 2 : is a flow chart of a second embodiment of a third-party library file vulnerability detection method provided by the present application, the method comprising:

[0059] Step 21: Get the third-party library file to be tested.

[0060] In this embodiment, the third-party library file is an Android third-party library file.

[0061] Step 22: Parse the third-party library file to be detected to obtain a Java class set.

[0062] The programming language of Android is Java, so there are many Java classes in the Android third-party library files. Therefore, the third-party library files to be detected are parsed to obtain a Java class set.

[0063] In some embodiments, the Android third-party library file may include two formats, such as the first format of the Android third-party library file may be in JAR format, and the second format of the Android third-party library file may be in AAR format.

[0064] When the format of the third-party library file to be detected is the first format, the third-party library file to be detected is parsed to obtain a Java class set. Specifically, if the format of the third-party library file to be detected is the JAR format, the class file set is parsed in the form of an unzipped file, and for any class file, there is a corresponding Java class. The class file name is removed from the file format suffix ".class" and stored in the Java class set, and the Java class set is defined as JavaClassesList.

[0065] When the format of the third-party library file to be detected is the second format, the third-party library file to be detected is parsed to obtain a Java class set and an Android component class set. If the format of the third-party library file to be detected is AAR format, the AndroidManifest.xml file and the classes.jar file are parsed in the form of decompressed files. The Android component class information declared in AndroidManifest.xml is collected to obtain an Android component class set, and the Android component class set is defined as ComponentList. The classes.jar file is parsed to obtain a class file set, and the class file name is removed from the file format suffix ".class" and stored in a Java class set, which is defined as JavaClassesList. It can be understood that the Android component class is essentially composed of Java classes, so the Android component class also exists in the classes.jar file. Therefore, there is also an Android component class in the Java class set. The basic information of the Android component class is recorded in the Android component class set. Such as the path of the Android component class.

[0066] Step 23: Compare the Java class set with the benchmark class set of the benchmark third-party library file to determine the incremental class set and the deleted class set in the Java class set, and use the files of the incremental class set and the deleted class set as incremental files.

[0067] In some embodiments, the Java class set includes different Java classes, and the benchmark class set includes different benchmark Java classes. The benchmark class set is obtained by parsing a benchmark third-party library file. Specifically, when the format of the benchmark third-party library file is the first format, the benchmark third-party library file is parsed to obtain the benchmark class set. Specifically, if the format of the benchmark third-party library file is the JAR format, the class file set is parsed in the form of an unzipped file, and for any class file, there is a corresponding Java class. The class file name is removed from the file format suffix ".class" and stored in the benchmark class set.

[0068] When the format of the benchmark third-party library file is the second format, parse the benchmark third-party library file to obtain a benchmark class set and a benchmark Android component class set. If the format of the benchmark third-party library file is AAR format, parse the AndroidManifest.xml file and the classes.jar file in the form of decompressed files. Collect the Android component class information declared in AndroidManifest.xml to obtain a benchmark Android component class set. Parse the classes.jar file to obtain the class file set, remove the file format suffix ".class" from the class file name and store it in the benchmark class set.

[0069] By comparing the Java class set with the benchmark class set of the benchmark third-party library file, the incremental class set and the deleted class set in the Java class set can be determined in the following way: if there are Java classes in the Java class set but not in the benchmark class set, these Java classes can be added to the incremental class set.

[0070] If there are Java classes that do not exist in the Java class set but exist in the base class set, these Java classes can be added to the deleted class set.

[0071] In some embodiments, see Figure 3 , step 23 may be the following process:

[0072] Step 31: traverse the benchmark class set to determine whether there is a second target class in the Java class set with the same class name as the first target class in the benchmark class set.

[0073] Since the benchmark class set is obtained based on the benchmark third-party library file, by judging whether there is a second target class in the Java class set with the same class name as the first target class in the benchmark class set, it can be determined whether the Java class in the third-party library file to be detected has been changed, such as whether a Java class has been deleted in the third-party library file to be detected.

[0074] In step 31 , if it is determined that there is no second target class in the Java class set having the same class name as the first target class in the reference class set, step 32 is executed.

[0075] If it is determined that there is no second target class in the Java class set with the same class name as the first target class in the benchmark class set, it means that the second target class with the same class name as the first target class has been deleted when the third-party library file to be detected is prepared.

[0076] If it is determined that there is a second target class in the Java class set with the same class name as the first target class in the reference class set, step 33 is executed. This indicates that when preparing the third-party library file to be detected, the second target class with the same class name as the first target class is retained, and further judgment is required.

[0077] Step 32: Add the first target class to the deleted class set.

[0078] At this point, the first target class can be added as an incremental file to the deleted class set.

[0079] Step 33: Determine a first verification value for the first target class, and obtain a second verification value for the second target class.

[0080] When determining that there is a second target class in the Java class set with the same class name as the first target class in the reference class set, it is not possible to determine whether the second target class has been modified. Therefore, a corresponding check value is generated for each target class after programming is successful. The check value is unique.

[0081] For example, the MD5 verification algorithm may be used to generate a corresponding verification value for each target class.

[0082] Therefore, the first target class corresponds to the first check value, and the second target class corresponds to the second check value.

[0083] Step 34: Determine whether the first verification value is the same as the second verification value.

[0084] Since the class names of the first target class and the second target class are the same, if the second target class is not modified when the third-party library file to be detected is produced, the second check value of the second target class is the same as the first check value.

[0085] If the second target class is modified when the third-party library file to be detected is produced, the second check value changes and is different from the first check value.

[0086] In step 34 , if it is determined that the first verification value is the same as the second verification value, step 35 is executed; if it is determined that the first verification value is different from the second verification value, step 36 is executed.

[0087] Step 35: Delete the second target class in the Java class collection.

[0088] Because the first check value is the same as the second check value, the second target class corresponding to the second check value has been tested for vulnerabilities as the first target class in the benchmark third-party library file. Therefore, the second target class cannot be counted as an incremental file. Therefore, the second target class is deleted from the Java class set, and the second target class is not added to the incremental class set or the deleted class set.

[0089] Step 36: Add the second target class to the incremental class set.

[0090] Since the first check value is different from the second check value, it means that the second target class corresponding to the second check value has changed. Therefore, the second target class is counted as an incremental file and added to the incremental class set.

[0091] When the second target class is added to the incremental class set, it is also deleted from the Java class set.

[0092] In some embodiments, after the traversal of the benchmark class set is completed, the Java classes in the Java class set may not have been completely screened. For example, there are Java classes in the Java class set that do not exist in the benchmark class set at all. This indicates that these Java classes are newly added in the third-party library file to be detected this time, so these Java classes also need to be added to the incremental class set.

[0093] That is, the second target class in the Java class set whose class name is different from that of the first target class is added to the incremental class set.

[0094] In the above process, by traversing the baseline class set and determining whether there is a second target class in the Java class set with the same class name as the first target class in the baseline class set, it is possible to determine whether the Java class in the baseline class set has been deleted or modified in the Java class set, and whether a new Java class that is not in the baseline class set has been added to the Java class set, thereby determining all incremental files.

[0095] Step 24: Perform vulnerability detection on the incremental file to obtain incremental vulnerability information.

[0096] In some embodiments, the analysis framework soot can be used to parse the binary code of the incremental file into intermediate code and generate a control flow graph CFG and an inter-procedural call graph ICFG.

[0097] In some embodiments, see Figure 4 , step 24 may be the following process:

[0098] Step 41: Call the target call flow graph; wherein the target call flow graph is constructed based on a third-party library file.

[0099] Step 42: Filter the incremental class set and the deleted class set to obtain an incremental entry function set.

[0100] In some embodiments, for the baseline path class set PathClassesList and the baseline taint path set BaseTaintList of each baseline entry function in the baseline vulnerability information, the node classes in the baseline path class set PathClassesList are traversed. If the node class is included in the incremental class set or the deleted class set, the baseline entry function corresponding to the node class is added to the incremental entry function set, and the baseline path class and baseline taint path of the baseline entry function are deleted from the baseline vulnerability information to obtain new baseline vulnerability information.

[0101] In the above process, if the node class is included in the incremental class set or the deleted class set, it means that the node class may be modified or deleted, so it needs to be re-detected for vulnerabilities, so it is deleted from the baseline vulnerability information.

[0102] For any Java class in the incremental class set, construct a dummy main function dummyMainI, add the public functions of the Java class to the dummy main function dummyMainI, and finally add the dummy main function dummyMainI to the incremental entry function set.

[0103] Step 43: Perform data flow analysis on any entry function in the incremental entry function set based on the target call flow graph to obtain incremental vulnerability information.

[0104] In some embodiments, see Figure 5 , step 43 may be the following process:

[0105] Step 51: During the data flow analysis process, each node class is added to the incremental path class set, and it is determined whether the node class contains a taint source.

[0106] If it is determined that the node class contains a taint source, step 52 is executed.

[0107] Step 52: Perform taint analysis on the data stream.

[0108] Step 53: If the node class contains a taint sink and is infected by a taint source, add the taint path of the node class to the incremental taint path set.

[0109] Step 54: Add the incremental path class set and the incremental taint path set to the incremental vulnerability information.

[0110] In some embodiments, data flow analysis is performed by traversing all entry function methods in the incremental entry function set. For example, the target entry function is first determined from the incremental entry function set, and then data flow analysis is performed. For any node class in the data flow, the node class is added to the incremental path class set IncrementPathClassesList, and it is determined whether the node class contains the source taint source. If it does, the data flow is subjected to taint analysis. If the node class contains a sink taint collection point and has been infected by the taint source, the taint path corresponding to the node class is added to the incremental taint path set. After the data flow analysis is completed, the incremental path class set and the incremental taint path set are added to the incremental vulnerability information.

[0111] Step 25: Use the incremental vulnerability information to update the baseline vulnerability information to obtain the latest baseline vulnerability information, wherein the baseline vulnerability information is obtained based on the detection of the baseline third-party library file.

[0112] In some embodiments, the new baseline vulnerability information and incremental vulnerability information after deleting the baseline path class and the baseline tainted path of the baseline entry function are integrated to obtain the latest baseline vulnerability information.

[0113] In an application scenario, it is necessary to perform vulnerability detection on multiple third-party library files to be detected. Each third-party library file to be detected corresponds to a different version of the same product. It is understandable that different versions of third-party library files are usually modified on the basis of previous versions during development. Therefore, multiple third-party library files to be detected are sorted according to versions. First, vulnerability detection is performed on the third-party library files to be detected with lower versions in the manner of the above embodiment to obtain the latest baseline vulnerability information.

[0114] Then the latest baseline vulnerability information is used as the baseline vulnerability information for the next round of vulnerability detection, so as to complete the vulnerability detection of all versions of the third-party library files to be detected.

[0115] In this embodiment, the third-party library file to be detected is compared with the baseline third-party library file to determine the incremental file, which can reduce the size of the files involved in subsequent vulnerability detection, and can perform vulnerability detection on the incremental file to quickly obtain incremental vulnerability information, and then use the incremental vulnerability information to update the baseline vulnerability information. There is no need to perform full detection on the third-party library file to be detected, thereby improving the efficiency of vulnerability detection on the third-party library file to be detected.

[0116] And when performing vulnerability detection on multiple versions of third-party library files to be detected, the above method is used to determine the incremental files for each third-party library file to be detected, thereby reducing the size of files subsequently involved in vulnerability detection, and being able to perform vulnerability detection on incremental files, quickly obtain incremental vulnerability information, and then use the incremental vulnerability information to update baseline vulnerability information. This can solve the problem of redundant workload when batch processing multiple versions of third-party library files to be detected, and improve the efficiency of vulnerability detection on multiple versions of third-party library files to be detected.

[0117] See also Figure 6 , Figure 6 : is a flow chart of a third embodiment of a third-party library file vulnerability detection method provided by the present application, the method comprising:

[0118] Step 61: Obtain the third-party library file to be detected.

[0119] Step 62: Determine whether a benchmark third-party library file exists.

[0120] In step 62, if it is determined that there is no baseline third-party library file, step 63 is executed. If it is determined that there is a baseline third-party library file, the third-party library file to be detected is compared with the baseline third-party library file to determine the incremental file. Then, vulnerability detection is performed on the incremental file to obtain incremental vulnerability information.

[0121] Step 63: The third-party library file to be detected is used as a benchmark third-party library file, and vulnerability detection is performed on the third-party library file to be detected to obtain initial vulnerability information.

[0122] Step 64: Use the initial vulnerability information as baseline vulnerability information.

[0123] In some embodiments, the third-party library file is an Android third-party library file. Step 63 may be the following process:

[0124] When the format of the third-party library file to be detected is the first format, the third-party library file to be detected is parsed to obtain a Java class set. Specifically, if the format of the third-party library file to be detected is the JAR format, the class file set is parsed in the form of an unzipped file, and for any class file, there is a corresponding Java class. The class file name is removed from the file format suffix ".class" and stored in the Java class set, and the Java class set is defined as JavaClassesList.

[0125] When the format of the third-party library file to be detected is the second format, the third-party library file to be detected is parsed to obtain a Java class set and an Android component class set. If the format of the third-party library file to be detected is AAR format, the AndroidManifest.xml file and the classes.jar file are parsed in the form of decompressed files. The Android component class information declared in AndroidManifest.xml is collected to obtain an Android component class set, and the Android component class set is defined as ComponentList. The classes.jar file is parsed to obtain a class file set, and the class file name is removed from the file format suffix ".class" and stored in a Java class set, which is defined as JavaClassesList. It can be understood that the Android component class is essentially composed of Java classes, so the Android component class also exists in the classes.jar file. Therefore, there is also an Android component class in the Java class set. The basic information of the Android component class is recorded in the Android component class set. Such as the path of the Android component class.

[0126] Then the code analysis framework soot is called to parse the binary code of the third-party library file to be detected into intermediate code, and generate a control flow graph CFG and an inter-procedural call graph ICFG.

[0127] For the Android component class set, traverse the Android component class set, for any of the Android component classes, construct a dummy main function dummyMainA, insert the lifecycle function and callback function of the component class into dummyMainA, and add dummyMainA to the entry function set. For Java classes, traverse the Java class set, for any of the Java classes, construct a dummy main function dummyMainJ, insert the public function of the Java class into dummyMainJ, and add dummyMainJ to the entry function set.

[0128] Traverse the entry function set, start data flow analysis for any entry function, add the node class to the path class set for any node in the data flow, and determine whether the node contains the source taint source. If it does, perform taint analysis on the data flow. If the node contains a sink point and has been infected by the taint source, add the taint path to the baseline taint path set. After the data flow analysis is completed, add the path class set and the baseline taint path set BaseTaintList to the baseline vulnerability information.

[0129] In one application scenario, combined with Figure 7-Figure 8To explain:

[0130] Step 71: Obtain the third-party library file to be detected from the multi-version third-party library file set.

[0131] The third-party library file set is a multi-version set of the same product, and the file format includes JAR or AAR. In each round of vulnerability detection, the third-party library file to be detected is taken from the set.

[0132] Step 72: Preprocess the third-party library file to be detected to obtain the Android component class set and Java public class set contained in the third-party library.

[0133] In some embodiments, see Figure 8 , step 72 may be the following process:

[0134] Determine whether the third-party library file to be detected is in JAR format. If so, parse the class file set in the form of decompressed files. For any class file, there is a corresponding Java class. Remove the file format suffix ".class" from the class file name and store it in the Java class set.

[0135] If not, the file is in AAR format, then parse out AndroidManifest.xml and classes.jar in the form of decompressed files. Collect the Android component class set information declared in AndroidManifest.xml and define it as ComponentList.

[0136] Continue to parse the classes.jar file to obtain the class file set, remove the file format suffix ".class" from the class file name and store it in the Java class collection.

[0137] Step 73: Compare the Java public class set with the benchmark class set in the benchmark vulnerability information, and filter to obtain the incremental class set and the deleted class set of the third-party library file to be detected.

[0138] Among them, the baseline vulnerability information is the analysis result of the baseline version of the third-party library, including the baseline taint path set, the baseline class set, and the path class set; the baseline class set includes the Java public class set of the baseline version of the third-party library and the MD5 of their class files; the incremental class set includes the newly added or modified Java public class set of the third-party library file to be detected; the deleted class set is the Java public set deleted by the third-party library file to be detected based on the baseline version.

[0139] Specifically, the incremental class set and the deleted class set are obtained according to the reference class set and the Java class set generated in step 73, and the process is as follows:

[0140] Determine whether the third-party library file to be detected is a benchmark version. If so, there is currently no valid benchmark class set. Based on the class file set and the Java class set, for each Java class in the Java class set, calculate the MD5 of the corresponding class file and store it in a mapping table, defined as ClassMD5Map, which stores the mapping relationship between the class name and the class file MD5.

[0141] In particular, the incremental class set and the deleted class set of the third-party library files of the baseline version are both empty sets.

[0142] Otherwise, traverse the benchmark class set ClassMD5Map, and for each benchmark class and its MD5 value, determine whether there is a target class with the same class name as the benchmark class in the Java class set. If not, it indicates that the benchmark class has been deleted in the third-party library file to be detected, and the benchmark class is added to the deleted class set; if it exists, calculate the MD5 value of the target class. If the MD5 value of the benchmark class is the same as the MD5 value of the target class, it indicates that the target class and the benchmark class are the same class and do not belong to the incremental class set, and the target class is deleted from the Java class set; if they are not the same, it indicates that the target class has been modified in the third-party library file to be detected and belongs to the incremental class set, then update the MD5 value of the benchmark class in ClassMD5Map to the MD5 value of the target class, and add the target class to the incremental class set, and finally delete the target class from the Java class set.

[0143] After the above traversal is completed, the Java class set is traversed again. For each remaining Java class, it is indicated that each remaining Java class does not exist in the benchmark class set ClassMD5Map and belongs to the incremental class set. Each remaining Java class is added to the incremental class set. Further, the MD5 value of each remaining Java class is calculated and the ClassMD5Map is updated, and finally each remaining Java class is deleted from the Java class set.

[0144] Step 74: construct an ICFG for the third-party library file to be detected, and filter out the incremental entry function set according to the incremental class set and the deleted class set, perform static taint analysis on the constructed ICFG and the preset source function set and sink function set, and obtain the incremental taint path.

[0145] Among them, the incremental entry function set includes the baseline entry function of the path class set that contains the incremental class set or the deletion class set and the entry function generated by the incremental class set.

[0146] In some embodiments, the acquired incremental class set is subjected to incremental data flow analysis. Specifically, the open source code analysis framework soot is called to parse the binary code of the third-party library file to be detected into intermediate code, and generate a control flow graph CFG and an inter-procedural call graph ICFG. It is determined whether the third-party library file to be detected is a baseline version. If so, there is no baseline taint path set.

[0147] Therefore, for Android component classes, traverse the component class set, for any of them, construct a dummy main function dummyMainA, insert the life cycle function and callback function of the component class into dummyMainA, and add dummyMainA to the entry function set (set as EntranceList). For Java classes, traverse JavaClassesList, for any of them, construct a dummy main function dummyMainJ, insert the public function of the Java class into dummyMainJ, and add dummyMainJ to the entry function set EntranceList.

[0148] Then traverse the entry function set EntranceList, start data flow analysis for any entry function Entrance, add the node class to the path class set for any node in the data flow, and determine whether the node contains the source taint source. If it does, perform taint analysis on the data flow. If the node contains a sink point and has been infected by the taint source, add the taint path to the baseline taint path set BaseTaintList. After the data flow analysis is completed, add the path class set PathClassesList and the baseline taint path set BaseTaintList to the baseline vulnerability information.

[0149] If it is determined that the third-party library file to be detected is not the baseline version, then for the path class set PathClassesList and the baseline tainted path set BaseTaintList of each entry function Entrance in the baseline vulnerability information, traverse the node classes in PathClassesList, if the incremental class set or the deleted class set contains the node class, then add the corresponding entry function to the entry function set EntranceList, and delete the path class and baseline tainted path of the entry function from the baseline vulnerability information; for any incremental class in the incremental class set, construct a dummy main function dummyMainI, and add the public function of the incremental class to dummyMainI, and finally add dummyMainI to the entry function set IncrementEntranceList.

[0150] Then, traverse the entry function set IncrementEntranceList, start data flow analysis for any entry function Entrance, add the node class to the path class set IncrementPathClassesList for any node in the data flow, and determine whether the node contains the source taint source. If it does, perform taint analysis on the data flow. If the node contains a sink convergence point and has been infected by the taint source, add the taint path to the incremental taint path set. After the data flow analysis is completed, add the path class set IncrementPathClassesList and the incremental taint path set IncrementalTaintList to the incremental vulnerability information.

[0151] Step 75: According to the incremental taint path, combined with the baseline taint path set in the baseline vulnerability information, complete third-party library vulnerability information is obtained.

[0152] Third-party library vulnerability information includes the tainted path set of the third-party library.

[0153] In some embodiments, the baseline vulnerability information is integrated with the incremental vulnerability information generated in step 74 to obtain complete Android third-party library vulnerability information, and the baseline vulnerability information is updated for the next round of incremental version analysis.

[0154] Specifically, each entry path class set and incremental taint path set generated in step 74 are added to the Android third-party library vulnerability information; each filtered entry baseline path class set and baseline taint path set are added to the Android third-party library vulnerability information.

[0155] Step 76: Update the baseline vulnerability information according to the third-party library vulnerability information.

[0156] Update the baseline vulnerability information according to the above Android third-party library vulnerability information. For example, use the current version of Android third-party library vulnerability information as the baseline vulnerability information for the next round of analysis.

[0157] Step 77: Determine whether vulnerability detection has been completed in all sets of multi-version third-party library files.

[0158] In step 77, if there are still third-party library files for which vulnerability detection has not been completed, vulnerability detection is continued for the third-party library files for which vulnerability detection has not been completed according to step 71. Otherwise, vulnerability detection is terminated.

[0159] See also Fig. 9 , Fig. 9 : is a comparison diagram of the third-party library file vulnerability detection method provided by this application and related solutions. Fig. 9In the present invention, the technical solutions and related technical solutions are used to detect vulnerabilities in five versions of third-party library files. Fig. 9 The detection time is shown.

[0160] Specifically, the technical solutions of the present application and related technical solutions are used to perform vulnerability detection on three versions of the third-party library files, 6.5.0, 6.8.1, 6.9.2, 7.1.0 and 7.2.0, respectively. The file sizes of the three-party library files of the five versions are 18.7MB (Mbyte), 17.8MB, 17.8MB, 14.2MB and 14.5MB, respectively.

[0161] Among them, the time taken by the relevant technical solution to perform vulnerability detection on five versions of third-party library files was 144s, 157s, 195s, 145s and 129s respectively.

[0162] The time taken by the technical solution of the present application to perform vulnerability detection on five versions of third-party library files is 146s, 128s, 42s, 127s and 75s respectively.

[0163] It can be seen from this that compared with the related technical solutions, the technical solution of the present application reduces the vulnerability detection time in all versions of the third-party library files except the benchmark third-party library file (version number 6.5.0), and achieves an improvement of 12% to 78% based on version changes.

[0164] That is, the incremental data flow analysis proposed in this application continuously updates the baseline vulnerability information when batch processing multiple versions of Android third-party libraries, and compares it with the latest version of the third-party library to filter out the version incremental class set and the deleted class set, so that the data flow analysis focuses on the incremental code and greatly reduces repetitive work.

[0165] See also Fig.10 , Fig.10 It is a flow chart of an embodiment of a third-party library file vulnerability detection device provided in the present application. The third-party library file vulnerability detection device 140 includes: an acquisition module 141, a comparison module 142, a detection module 143 and an update module 144.

[0166] Wherein, the acquisition module 141 is used to obtain the third-party library file to be detected;

[0167] The comparison module 142 is used to compare the third-party library file to be detected with the benchmark third-party library file to determine the incremental file.

[0168] The detection module 143 is used to perform vulnerability detection on incremental files to obtain incremental vulnerability information.

[0169] The update module 144 is used to update the baseline vulnerability information using the incremental vulnerability information to obtain the latest baseline vulnerability information, wherein the baseline vulnerability information is obtained based on the detection of the baseline third-party library file.

[0170] It can be understood that the third-party library file vulnerability detection device 140 can implement the method of any of the above embodiments by using the acquisition module 141 , the comparison module 142 , the detection module 143 and the update module 144 .

[0171] See also Fig.11 , Fig.11 1 is a schematic diagram of the structure of an embodiment of an electronic device provided by the present application. The electronic device 110 includes a processor 111 and a memory 112 coupled to the processor 111; wherein the memory 112 is used to store a computer program, and the processor 111 is used to execute the computer program to implement the following method:

[0172] Obtain the third-party library file to be detected; compare the third-party library file to be detected with the baseline third-party library file to determine the incremental file; perform vulnerability detection on the incremental file to obtain incremental vulnerability information; use the incremental vulnerability information to update the baseline vulnerability information to obtain the latest baseline vulnerability information, wherein the baseline vulnerability information is obtained based on the detection of the baseline third-party library file.

[0173] It can be understood that the processor 111 is used to execute a computer program to implement the method of any of the above embodiments.

[0174] See also Fig.12 , Fig.12 It is a structural diagram of another embodiment of the electronic device provided by the present application. The electronic device 110 may be, for example, a mobile electronic device, and the electronic device 110 may include: a memory 112, a processor (Central Processing Unit, CPU) 111, a circuit board (not shown in the figure), a power circuit and a microphone 123. The circuit board is placed inside the space surrounded by the shell; the processor 111 and the memory 112 are arranged on the circuit board; the power circuit is used to supply power to various circuits or devices of the electronic device; the memory 112 is used to store executable program codes; the processor 111 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 112, so as to identify the above-mentioned identification information to realize the unlocking and wake-up functions.

[0175] The electronic device may also include: a peripheral interface 114, an RF (Radio Frequency) circuit 116, an audio circuit 117, a speaker 122, a power management chip 119, an input / output (I / O) subsystem 120, other input / control devices 121, a display 113 and an external port 115. These components communicate through one or more communication buses or signal lines 118.

[0176] The memory 112 can be accessed by the processor 111, the peripheral interface 114, etc. The memory 112 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more disk storage devices, flash memory devices, or other volatile solid-state storage devices. The peripheral interface 114 can connect the input and output peripherals of the device to the processor 111 and the memory 112.

[0177] The I / O subsystem 120 can connect the input and output peripherals on the device, such as the display 113 and other input / control devices 121, to the peripheral interface 114. The I / O subsystem 120 may include a display controller 1201 and one or more input controllers 1202 for controlling other input / control devices 121. Among them, the one or more input controllers 1202 receive electrical signals from other input / control devices 121 or send electrical signals to other input / control devices 121. Other input / control devices 121 may include physical buttons (press buttons, rocker buttons, etc.), dials, slide switches, joysticks, and click wheels. It is worth noting that the input controller 1202 can be connected to any of the following: a keyboard, an infrared port, a USB interface, and a pointing device such as a mouse.

[0178] The display 113 is an input interface and an output interface between the user electronic device and the user, and displays visual output to the user. The visual output may include graphics, text, icons, videos, etc.

[0179] The display controller 1201 in the I / O subsystem 120 receives an electrical signal from the display 113 or sends an electrical signal to the display 113. The display 113 detects contact on the touch screen, and the display controller 1201 converts the detected contact into interaction with a user interface object displayed on the display 113, that is, realizes human-computer interaction. The user interface object displayed on the display 113 may be an icon for running a game, an icon for connecting to a corresponding network, etc.

[0180] The RF circuit 116 is mainly used to establish communication between the mobile phone and the wireless network (i.e., the network side) to realize data reception and transmission between the mobile phone and the wireless network. For example, sending and receiving short messages, emails, etc. Specifically, the RF circuit 116 receives and sends RF signals, which are also called electromagnetic signals. The RF circuit 116 converts electrical signals into electromagnetic signals or converts electromagnetic signals into electrical signals, and communicates with the communication network and other devices through the electromagnetic signals. The RF circuit 116 may include known circuits for performing these functions, including but not limited to antenna systems, RF transceivers, one or more amplifiers, tuners, one or more oscillators, digital signal processors, CODEC (COder-DECoder, codec) chipsets, Subscriber Identity Module (SIM), etc.

[0181] The audio circuit 117 is mainly used to receive audio data from the peripheral interface 114, convert the audio data into an electrical signal, and send the electrical signal to the speaker 122. The speaker 122 is used to restore the voice signal received by the mobile phone from the wireless network through the RF circuit 116 to sound and play the sound to the user. The power management chip 119 is used to provide power supply and power management for the processor 111, the I / O subsystem 120 and the hardware connected to the peripheral interface 114.

[0182] See also Fig.13 , Fig.13 1 is a schematic diagram of a computer readable storage medium according to an embodiment of the present application. The computer readable storage medium 130 stores a computer program 131. When the computer program 131 is executed by a processor, the following method is implemented:

[0183] Obtain the third-party library file to be detected; compare the third-party library file to be detected with the baseline third-party library file to determine the incremental file; perform vulnerability detection on the incremental file to obtain incremental vulnerability information; use the incremental vulnerability information to update the baseline vulnerability information to obtain the latest baseline vulnerability information, wherein the baseline vulnerability information is obtained based on the detection of the baseline third-party library file.

[0184] It can be understood that when the computer program 131 is executed by a processor, it can also implement the method of any of the above embodiments.

[0185] To summarize, the present application utilizes the technical solution of any of the above-mentioned embodiments to compare the third-party library file to be detected with the baseline third-party library file to determine the incremental file, which can reduce the size of files involved in subsequent vulnerability detection, and can perform vulnerability detection on the incremental file, quickly obtain incremental vulnerability information, and then use the incremental vulnerability information to update the baseline vulnerability information. There is no need to perform full detection on the third-party library file to be detected, thereby improving the efficiency of vulnerability detection on the third-party library file to be detected.

[0186] And when performing vulnerability detection on multiple versions of third-party library files to be detected, the above method is used to determine the incremental files for each third-party library file to be detected, thereby reducing the size of files subsequently involved in vulnerability detection, and being able to perform vulnerability detection on incremental files, quickly obtain incremental vulnerability information, and then use the incremental vulnerability information to update baseline vulnerability information. This can solve the problem of redundant workload when batch processing multiple versions of third-party library files to be detected, and improve the efficiency of vulnerability detection on multiple versions of third-party library files to be detected.

[0187] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device implementation described above is only illustrative, for example, the division of the modules or units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0188] If the integrated units in the above other embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), disk or optical disk and other media that can store program codes.

[0189] The above description is only an implementation method of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly used in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A third-party library file vulnerability detection method, characterized in that: The method comprises: Obtain a third-party library file to be detected; the third-party library file is an Android third-party library file; Parsing the third-party library file to be detected to obtain a Java class set; Traversing the benchmark class set of the benchmark third-party library file, determining whether there is a second target class in the Java class set that has the same class name as the first target class in the benchmark class set; If not, then adding the first target class to the deleted class set; If so, determining a first check value for the first target class, and obtaining a second check value for the second target class; Determining whether the first verification value is the same as the second verification value; If yes, deleting the second target class in the Java class set; If not, then add the second target class to the incremental class set, and after traversing the baseline class set, add the second target class in the Java class set that has a different class name from the first target class to the incremental class set, and use the files of the incremental class set and the deleted class set as incremental files; Performing vulnerability detection on the incremental file to obtain incremental vulnerability information; The incremental vulnerability information is used to update the baseline vulnerability information to obtain the latest baseline vulnerability information, wherein the baseline vulnerability information is obtained based on the baseline third-party library file detection.

2. The method according to claim 1, characterized in that The third-party library file to be detected is parsed to obtain a Java class set, including: When the format of the third-party library file to be detected is the first format, parsing the third-party library file to be detected to obtain the Java class set; When the format of the third-party library file to be detected is the second format, the third-party library file to be detected is parsed to obtain the Java class set and the Android component class set.

3. The method according to claim 1, characterized in that The step of performing vulnerability detection on the incremental file to obtain incremental vulnerability information includes: Calling a target call flow graph; wherein the target call flow graph is constructed based on the third-party library file; Filtering the incremental class set and the deleted class set to obtain an incremental entry function set; Based on the target call flow graph, data flow analysis is performed on any entry function in the incremental entry function set to obtain the incremental vulnerability information.

4. The method according to claim 3, characterized in that The step of performing data flow analysis on any entry function in the incremental entry function set based on the target call flow graph to obtain the incremental vulnerability information includes: During the data flow analysis, each node class is added to the incremental path class set, and it is determined whether the node class contains a taint source; If so, performing taint analysis on the data stream; If the node class contains a taint sink and is infected by the taint source, adding the taint path of the node class to the incremental taint path set; The incremental path class set and the incremental taint path set are used as the incremental vulnerability information.

5. The method according to claim 1, characterized in that Before comparing the third-party library file to be detected with the benchmark third-party library file to determine the incremental file, the method includes: Determine whether the benchmark third-party library file exists; If not, taking the third-party library file to be detected as the benchmark third-party library file, and performing vulnerability detection on the third-party library file to be detected to obtain initial vulnerability information; The initial vulnerability information is used as the baseline vulnerability information.

6. A third-party library file vulnerability detection device, characterized in that: The third-party library file vulnerability detection device comprises: An acquisition module is used to acquire a third-party library file to be detected; the third-party library file is an Android third-party library file; A comparison module is used to parse the third-party library file to be detected to obtain a Java class set; traverse the benchmark class set of the benchmark third-party library file to determine whether there is a second target class with the same class name as the first target class in the benchmark class set in the Java class set; if not, add the first target class to the deleted class set; if so, determine a first check value of the first target class, and obtain a second check value of the second target class; determine whether the first check value is the same as the second check value; if so, delete the second target class in the Java class set; if not, add the second target class to the incremental class set, and after traversing the benchmark class set, add the second target class in the Java class set that is not the same as the first target class name to the incremental class set, and use the files of the incremental class set and the deleted class set as incremental files; A detection module, used to perform vulnerability detection on the incremental file to obtain incremental vulnerability information; The update module is used to update the baseline vulnerability information using the incremental vulnerability information to obtain the latest baseline vulnerability information, wherein the baseline vulnerability information is obtained based on the detection of the baseline third-party library file.

7. An electronic device, characterized in that: The electronic device includes a processor and a memory coupled to the processor; The memory is used to store a computer program, and the processor is used to execute the computer program to implement the method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the computer program implements the method according to any one of claims 1 to 5.

Images