Vulnerability reachability analysis method of binary mode open source component and related equipment

Abstract

The invention provides a vulnerability reachability analysis method for a binary mode open source component and related equipment, and the method comprises the steps: determining a target open source component used in to-be-detected software in a binary form, and recognizing the version information of the target open source component; determining a target vulnerability in a vulnerability query database according to the identifier and version information of the target open source component, and extracting a vulnerability function of the target vulnerability; and based on the target vulnerability, extracting a calling relationship between an entry program of the to-be-detected software and the target open source component, and generating a first calling graph. And according to the first call graph, extracting an import function used for calling the target open source software in the to-be-detected software. And determining a source code warehouse address of a target open source component contained in the first call graph, obtaining a source code of the target open source component from the source code warehouse address, and generating a second call graph. And based on the vulnerability function, the import function and the second call graph, determining whether the vulnerability function has accessibility in the to-be-detected software.

Description

Technical Field

[0001] The present application relates to the field of software supply chain security technology, and in particular to a vulnerability accessibility analysis method for open source components in binary mode and related equipment. Background Art

[0002] With the rapid development of open source projects and increasingly fierce market competition, more and more commercial software choose to introduce open source components to accelerate the software development process. In this way, commercial software can be put on the market as soon as possible, but this model brings some new challenges to the security of the entire software system. For example, when introducing open source components, vulnerabilities of open source components will be introduced. Due to the commercial nature of commercial software, the source code of commercial software is often not available. Most commercial software uses open source components in binary form, which brings new difficulties to software vulnerability analysis. Summary of the invention

[0003] In view of this, the purpose of this application is to propose a vulnerability reachability analysis method and related equipment for binary mode open source components to solve the problem that software using binary open source components cannot perform vulnerability reachability analysis.

[0004] Based on the above purpose, this application provides a vulnerability reachability analysis method for open source components in binary mode, including: Determine a target open source component used in the software to be detected in binary form, and identify version information of the target open source component; According to the identifier of the target open source component and the version information, determine the target vulnerability contained in the target open source component in a vulnerability query database, and extract the vulnerability function of the target vulnerability according to the data information of the target vulnerability; Based on the target vulnerability, extract the call relationship between the entry program of the software to be detected and the target open source component, and generate a first call graph through an aggregation method according to the call relationship; Extracting, according to the first call graph, an import function in the software to be detected that is used to call the target open source software; Determine a source code repository address of a target open source component included in the first call graph, obtain source code of the target open source component from the source code repository address, and generate a second call graph based on the source code using a generation tool; Based on the vulnerable function, the imported function and the second call graph, determine whether the vulnerable function is reachable in the software to be detected.

[0005] In some embodiments, determining the target open source component used in the software to be detected in binary form includes: Building a mapping database between open source components and open source binary component files included in the open source components; According to the target open source binary component file called in the software to be detected, the target open source component corresponding to the target open source binary component file is queried in the mapping database to determine.

[0006] In some embodiments, identifying the version information of the target open source component includes: In response to the version information not being identified according to the resource folder of the target open source component, identification is performed according to the version string of the target open source component; in response to the version information not being identified according to the version string of the target open source component, identification is performed according to an internal read-only string of the target open source component to determine the version information of the target open source component.

[0007] In some embodiments, extracting the call relationship between the entry program of the software to be detected and the target open source component based on the target vulnerability, and generating a first call graph by an aggregation method according to the call relationship includes: According to the target vulnerability, determining an entry program in the software to be detected that can call a target open source component containing the target vulnerability as a risk entry program; According to the risk entry program and the calling manner of the target open source component called by the software to be detected, the calling relationship between the risk entry program and the target open source component is extracted, and a first call graph is generated through an aggregation method according to the calling relationship.

[0008] In some embodiments, the calling relationship includes a first calling relationship and a second calling relationship; extracting the calling relationship between the risk entry program and the target open source component according to the calling manner in which the risk entry program and the software to be detected call the target open source component includes: In response to the calling mode being an implicit link, extracting an import table from the risk entry program, and parsing the import table to obtain a first calling relationship; In response to the calling mode being a display link, each function block in the risk entry program is disassembled, an identifier of a target open source component linked in each function block is extracted, and a second calling relationship is constructed.

[0009] In some embodiments, extracting the import function for calling the target open source software in the software to be detected according to the first call graph includes: In response to the software to be detected calling the target open source component through an implicit link, extracting an import table of a risk entry program for calling the target open source component, and determining the import function according to the import table; In response to the software to be detected calling the target open source component through a display link, the risk entry program used to call the target open source component is decompiled to obtain a decompiled function block; the export function set of the target open source component is determined, and candidate third-party functions are determined from the decompiled function block according to a retrieval tool function, and the third-party functions included in the export function set are used as the import functions.

[0010] In some embodiments, before using a generation tool to generate a second call graph based on the source code, the method further includes: The source code that does not correspond to the version information is removed from the source code.

[0011] In some embodiments, determining whether the vulnerable function is reachable in the software to be detected based on the vulnerable function, the imported function, and the second call graph includes: The position of the vulnerable function and the position of the imported function are anchored on the second call graph, and based on the position of the vulnerable function and the position of the imported function, a depth-first traversal algorithm is used to determine whether the vulnerable function is reachable in the software to be detected.

[0012] Based on the same inventive concept, the present application also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the method described in the first aspect when executing the computer program.

[0013] Based on the same inventive concept, the present application also provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute the method described in the first aspect.

[0014] As can be seen from the above, the present application provides a vulnerability accessibility analysis method and related equipment for a binary mode open source component, the method comprising: determining the target open source component used in the software to be detected in binary form, identifying the version information of the target open source component, and realizing rapid identification of the target open source component. According to the identification of the target open source component and the version information, the target vulnerability contained in the target open source component is determined in the vulnerability query database, and the vulnerability function of the target vulnerability is extracted according to the data information of the target vulnerability; based on the target vulnerability, the call relationship between the entry program of the software to be detected and the target open source component is extracted, and the first call graph is generated by the aggregation method according to the call relationship. The first call graph is a coarse-grained call relationship graph, which gives the call relationship between the entry program and the target open source component. According to the first call graph, the import function used to call the target open source software in the software to be detected is extracted. The source code warehouse address of the target open source component contained in the first call graph is determined, the source code of the target open source component is obtained from the source code warehouse address, and the second call graph is generated based on the source code using a generation tool. Through the mapping relationship between source code and binary, the construction of the binary open source component call graph is indirectly realized by constructing the function call graph of the source code. Based on the vulnerable function, the imported function and the second call graph, it is determined whether the vulnerable function is reachable in the software to be detected. The method of the present application makes it possible to analyze the vulnerability reachability of binary open source components, effectively reduces the probability of false positives of vulnerabilities, and greatly reduces the time cost of technicians to repair vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0016] Figure 1 A flowchart of a vulnerability reachability analysis method for a binary mode open source component according to an embodiment of the present application; Figure 2 A schematic diagram of performing vulnerability accessibility analysis on Ansys software according to an embodiment of the present application; Figure 3 A schematic diagram of the structure of a vulnerability reachability analysis device for an open source component in binary mode according to an embodiment of the present application; Figure 4 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0017] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0018] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be the usual meanings understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing in front of the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0019] As described in the background technology, open source components are introduced into most commercial software. Existing C / C++-based commercial software uses open source components mainly in two forms: first, the source code of the open source component is added to the commercial software and then compiled. Second, the compiled binary file is directly integrated into the commercial software, and the open source component is called through dynamic linking. The second method is more common. For commercial software, due to its commercial nature, the source code of the commercial software is often not available. The vast majority of commercial software uses open source components in binary form, which brings new difficulties to the software composition analysis SCA (Software Composition Analysis) of commercial software. At the same time, there are often more vulnerabilities in popular open source components, posing a greater security threat to commercial software.

[0020] At present, vulnerability reachability analysis is in great demand in the cybersecurity community. Vulnerability reachability is a technical capability that focuses on reducing the underreporting of SCA tools. That is, based on vulnerability database information and certain technical means, it accurately locates the vulnerability function and outlines the transmission path of the vulnerability function (within and between components), ultimately greatly reducing the SCA false positive rate or even infinitely approaching 0.

[0021] Unlike proprietary software, the code coverage in open source components is not high, because developers often use binary components for direct integration. This results in most vulnerabilities in open source components being unreachable vulnerabilities, and repairing unreachable vulnerabilities places a great burden on repairers. Therefore, a method is needed to reduce false positives of vulnerabilities through vulnerability accessibility analysis.

[0022] In view of this, this application proposes a vulnerability accessibility analysis method for open source components in binary mode to solve the problem that existing software component analysis tools cannot perform vulnerability accessibility analysis for open source components, especially for software in binary format, there is no effective analysis tool.

[0023] For ease of understanding, the definitions of terms used in this application are introduced as follows: 1. Risk entry program: risk source software, referred to as RSS. Commercial software may have many exe files, and these exe programs can be called entry programs. The exe program that calls the third-party open source component with a vulnerable function is a risk entry program.

[0024] 2. Entry function: source function, referred to as sf. For a third-party open source component, the risk entry program generally only calls a small number of export functions. For example, the risk entry program acp_grpcserver.exe in the software ANSYS only calls the uncompress and compress functions in the component zlib1.dll. The uncompress and compress functions are the entry functions of the risk entry program acp_grpcserver.exe for the zlib component.

[0025] 3. Export function: export function, referred to as ef. The third-party open source component will display the function API interface provided to the outside in the export table. The functions implemented internally in the function API are not exposed. The functions in the export table are exported functions.

[0026] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0027] This application provides a vulnerability accessibility analysis method for open source components in binary mode. Figure 1 , including the following steps: Step 102: determine the target open source component used in the software to be detected in binary form, and identify the version information of the target open source component.

[0028] Specifically, the software to be tested is software in binary form. The software to be tested is software to be analyzed for software components, and the accessibility of vulnerabilities in third-party open source components called in the software to be tested needs to be analyzed. First, it is necessary to determine which third-party open source components are included in the software to be tested.

[0029] Furthermore, we identify the target open source components used in the binary form of the software to be detected, including: Building a mapping database between open source components and open source binary component files included in the open source components; According to the target open source binary component file called in the software to be detected, the target open source component corresponding to the target open source binary component file is queried in the mapping database to determine.

[0030] Specifically, the open source component includes multiple open source binary component files. Exemplarily, the extension of the open source binary component file is .dll. Dynamic Link Library (DLL) is a way to implement the concept of a shared function library. The extension of these library functions is .dll. Collect an open source dll database, and build a mapping database between open source components and open source binary component files based on the open source dll database. In the mapping data, each open source component corresponds to all the open source binary component files it contains. Exemplarily, the open source component is zlib, and the open source binary component file is zlib1.dll. According to the identifier of the open source binary component file called in the software to be detected, search the constructed mapping database for the open source component corresponding to the identifier of the open source binary component file as the target open source component.

[0031] Further, identifying the version information of the target open source component includes: In response to the version information not being identified according to the resource folder of the target open source component, identification is performed according to the version string of the target open source component; in response to the version information not being identified according to the version string of the target open source component, identification is performed according to an internal read-only string of the target open source component to determine the version information of the target open source component.

[0032] Specifically, in this embodiment, the version information of the target open source component is identified based on different version identification methods according to actual conditions. Different version identification methods include three identification methods: resource folder identification method, version string identification method and internal read-only string identification method. The three identification methods are ranked from fast to slow in recognition efficiency, namely: resource folder identification method, version string identification method and internal read-only string identification method. First, the version information is identified according to the resource folder identification method with the highest recognition efficiency. If the resource folder is not empty, the information in the identified resource folder is used as the version information. Exemplarily, the information in the resource folder is VS_VERSIONINFO. If the version information is not identified according to the resource folder identification method, the version string identification method is used for identification, and the identified version string is used as the version information. Exemplarily, the version string is 1.0.0. If the version information is not identified according to the version string identification method, the internal read-only string identification method is used for identification, and the identified internal read-only string is used as the version information. Exemplarily, the internal read-only string is a read-only string in the .rdata segment of the PE (PortableExecutable) file. By adopting different version identification methods to identify version information step by step, the identification efficiency can be effectively improved.

[0033] Step 104: determine a target vulnerability included in the target open source component in a vulnerability query database according to the identifier of the target open source component and the version information, and extract a vulnerability function of the target vulnerability according to the data information of the target vulnerability.

[0034] Specifically, the vulnerability database records the vulnerabilities corresponding to each open source component, and for the same open source component, different versions correspond to different vulnerabilities. After the version information is determined through the above steps, the target vulnerability contained in the target open source component can be determined in the vulnerability query database based on the identification and version information of the target open source component. Collect the github commit information corresponding to the vulnerability number of the target vulnerability, and the github commit information is provided through a diff file. The specific format of the diff file is: mark the '+' sign in front of the added line and the '-' sign in front of the deleted line. The diff file will mark a diff difference mark at the beginning, and the difference mark format is similar to @@ *, *@@ * or *. The difference mark is matched by a regular string to determine the diff file, and then the function name in the diff file is extracted, which is the vulnerability function name of the target vulnerability. The vulnerability function location can be determined by the vulnerability function name.

[0035] Step 106: Based on the target vulnerability, extract the calling relationship between the entry program of the software to be detected and the target open source component, and generate a first calling graph through an aggregation method according to the calling relationship.

[0036] Specifically, the first call graph is a coarse-grained PE file call graph, which shows the situation of the entry program calling the third-party component, including not only the call path of the entry program directly calling the third-party component, but also the call path of the third-party component directly calling other third-party components. In order to analyze the calling relationship between the target open source component containing the target vulnerability and the entry program of the software to be detected, it is necessary to extract the calling relationship between the corresponding entry program and the target open source component according to the target vulnerability. For the target open source component that does not contain the target vulnerability, it is not necessary to extract the calling relationship with the entry program to reduce the amount of data for subsequent analysis.

[0037] Furthermore, based on the target vulnerability, extracting the call relationship between the entry program of the software to be detected and the target open source component, and generating a first call graph by an aggregation method according to the call relationship, includes: According to the target vulnerability, determining an entry program in the software to be detected that can call a target open source component containing the target vulnerability as a risk entry program; According to the risk entry program and the calling manner of the target open source component called by the software to be detected, the calling relationship between the risk entry program and the target open source component is extracted, and a first call graph is generated through an aggregation method according to the calling relationship.

[0038] Specifically, the entry program that calls the target open source component containing the target vulnerability is used as the risk entry program. As mentioned above, the ways in which the software to be detected calls third-party components include implicit links and explicit links. For different calling methods, the methods for determining the calling relationship are different. Therefore, it is necessary to extract the calling relationship between the risk entry program and the target open source component based on the risk entry program and the calling method.

[0039] Afterwards, the extracted direct call relationships are aggregated through an aggregation method to form a first call graph.

[0040] Further, the calling relationship includes a first calling relationship and a second calling relationship; the extracting the calling relationship between the risk entry program and the target open source component according to the calling manner of the risk entry program and the software to be detected calling the target open source component includes: In response to the calling mode being an implicit link, extracting an import table from the risk entry program, and parsing the import table to obtain a first calling relationship; In response to the calling mode being a display link, each function block in the risk entry program is disassembled, an identifier of a target open source component linked in each function block is extracted, and a second calling relationship is constructed.

[0041] Specifically, for implicit links, the import table is extracted from the risk entry program. Among them, the import table is an indispensable part of the PE file structure, also known as the input table or import function table. The import table is equivalent to the key for the exe file to communicate with the dll file. All the import function information will be written into the import table. After the PE file is mapped to the memory, Windows will load the corresponding dll file. The exe file finds the import function in the corresponding dll through the "import table" to complete the normal operation of the program. This dynamic connection process is all participated by the import table. After determining the import table, all the import functions can be determined from the import table. According to the import function, the corresponding target open source component can be found, and then the first call relationship between the risk entry program and the target open source component can be determined.

[0042] For explicit links, the risk entry program is disassembled using the ghidra tool. Each function block is traversed, and for function blocks that use four dynamic link library loading functions, namely LoadLibraryA, LoadLibraryW, LoadLibraryExA, and LoadLibraryExW, the target open source component names linked by these explicit link functions in each function block are extracted, thereby constructing the second calling relationship between the risk entry program and the target open source component under the explicit link.

[0043] The first calling relationship and the second calling relationship constitute a calling relationship between the risk entry program and the target open source component.

[0044] Step 108: Extract the import function in the software to be detected that is used to call the target open source software according to the first call graph.

[0045] Specifically, according to the different ways in which the software to be detected calls the target open source component, when extracting the imported function, it is also necessary to extract it according to different calling methods.

[0046] Furthermore, extracting the import function for calling the target open source software in the software to be detected according to the first call graph includes: In response to the software to be detected calling the target open source component through an implicit link, an import table of a risk entry program for calling the target open source component is extracted, and the import function is determined according to the import table.

[0047] Specifically, the import table includes two import methods, namely, import by function name and import by function number. For import by function name, you can directly extract the imported function. For import by function number, you can calculate the distance between the function number and the base address number to generate a corresponding dictionary of the function number and the function name, and then extract the imported function name.

[0048] In response to the software to be detected calling the target open source component through a display link, the risk entry program used to call the target open source component is decompiled to obtain a decompiled function block; the export function set of the target open source component is determined, and candidate third-party functions are determined from the decompiled function block according to a retrieval tool function, and the third-party functions included in the export function set are used as the import functions.

[0049] Specifically, the risk entry program is disassembled and decompiled to generate a separate decompiled function block structure. The export function set of the target open source component is extracted, and the export function set is used as the matching source. For each decompiled function block, the candidate third-party functions called by the search tool function, such as the GetProcAddress function, are found in the function block, and these candidate third-party functions are matched with the export functions in the export function set to determine whether each candidate third-party function is included in the export function set. If included, the candidate third-party function is determined as an import function. Through the above method, all import functions that may reach the vulnerable function when the software to be detected is running are determined.

[0050] Step 110: determine the source code repository address of the target open source component included in the first call graph, obtain the source code of the target open source component from the source code repository address, and generate a second call graph based on the source code using a generation tool.

[0051] Specifically, the source code repository address of the target open source component included in the first call graph is determined by a web crawling method, for example, the source code repository address of the target open source component can be determined by the name of the target open source component and the component github source code repository address mapping library. The open source code repository of the target open source component can be found through the source code repository address, and then the source code of the target open source component can be obtained from the open source code repository.

[0052] Furthermore, before using a generation tool to generate a second call graph based on the source code, the method further includes: removing source code that does not correspond to the version information from the source code.

[0053] Since the source code contains source code of target open source components of different versions, and this embodiment only needs to extract the source code of the target open source components of the corresponding version called by the software to be detected. Therefore, the source code obtained from the open source code repository that does not match the version information determined in the above embodiment can be eliminated, and only the source code matching the version information is retained, reducing the amount of subsequent data processing. Exemplarily, the source code repository can be cloned to the local through the git clone command, and the version corresponding to the detected version information can be switched to through the git checkout command.

[0054] Afterwards, for the source code after the elimination, the Doxygen document generation tool is modified to generate a function call graph in dot format, i.e., the second call graph. At the same time, in order to further speed up the generation of the second call graph, the visualization function in the Doxygen document generation tool can be optimized. After removing unnecessary visualization functions, the generation rate of the second call graph can be further improved.

[0055] In addition, for each C / C++ type source code file, after generating the second call graph of the dot type, the second call graph is parsed to generate a function call graph in json format to facilitate subsequent data processing.

[0056] Step 112: Based on the vulnerable function, the imported function and the second call graph, determine whether the vulnerable function is reachable in the software to be detected.

[0057] Specifically, after the vulnerable function and the imported function are determined through the aforementioned steps, the positions of the vulnerable function and the imported function may be anchored on the second call graph to further determine the reachability of the vulnerable function.

[0058] Further, based on the vulnerable function, the imported function and the second call graph, determining whether the vulnerable function is reachable in the software to be detected includes: The position of the vulnerable function and the position of the imported function are anchored on the second call graph, and based on the position of the vulnerable function and the position of the imported function, a depth-first traversal algorithm is used to determine whether the vulnerable function is reachable in the software to be detected.

[0059] Specifically, since the nodes on the second call graph are identified by function names, the location of the vulnerable function and the imported function can be anchored according to the names of the vulnerable function and the imported function. The path reachability is determined by the depth-first traversal algorithm, and the transfer path of the vulnerable function is outlined. The shortest reachable path can be extracted, and all reachable paths can also be extracted.

[0060] The vulnerability reachability analysis method for binary mode open source components provided by this application is described below through a specific embodiment.

[0061] The target open source binary component file of Ansys software is determined to be zlib1.dll, and the target open source component is determined to be zlib according to the mapping database between the open source component and the open source binary component file. By identifying the version information of the target open source component zlib, the version information is determined to be 1.2.13. Based on the version information, by querying the vulnerability database, it is determined that the vulnerability number corresponding to the target open source component zlib is CVE-2023-45853, and the vulnerability function name is zipOpenNewFileInZip4_64. When extracting the call relationship, it is determined that 14 risk entry programs all call the target open source component zlib, and the first call graph is generated by aggregation according to the call relationship. Exemplarily, one of the risk entry functions is ANSYS Inc\\ANSYSStudent\\v241\\ACP\\acp_grpcserver.exe, and the set of imported functions extracted according to the first call graph is ['deflateInit2_', 'inflateEnd', 'inflate', 'deflateEnd', 'deflate', 'inflateInit2_']. The source code of the target open source component zlib is obtained by crawling the source code repository address, and the second call graph is generated. The vulnerable function and each imported function are anchored in the second call graph, and the depth-first traversal algorithm is used to determine whether the vulnerable function zipOpenNewFileInZip4_64 is reachable. Figure 2 A schematic diagram showing vulnerability reachability analysis of Ansys software is shown. Figure 2 On the left is a collection of imported functions. Figure 2 The right side shows the anchoring process of the vulnerable function and the imported function on the second call graph. Figure 2 It can be seen that the import functions of the 14 risk entry programs cannot reach the vulnerable function, which proves that the vulnerability is unreachable for Ansys software and the repair priority can be lowered.

[0062] Based on the above steps 102 to 112, the vulnerability accessibility analysis method of a binary mode open source component provided in this embodiment includes: determining the target open source component used in the software to be detected in binary form, identifying the version information of the target open source component, and realizing rapid identification of the target open source component. According to the identification of the target open source component and the version information, the target vulnerability contained in the target open source component is determined in the vulnerability query database, and the vulnerability function of the target vulnerability is extracted according to the data information of the target vulnerability; based on the target vulnerability, the call relationship between the entry program of the software to be detected and the target open source component is extracted, and the first call graph is generated by the aggregation method according to the call relationship. The first call graph is a coarse-grained call relationship graph, which gives the call relationship between the entry program and the target open source component. According to the first call graph, the import function used to call the target open source software in the software to be detected is extracted. The source code warehouse address of the target open source component contained in the first call graph is determined, the source code of the target open source component is obtained from the source code warehouse address, and the second call graph is generated based on the source code using a generation tool. Through the mapping relationship between source code and binary, the construction of the binary open source component call graph is indirectly realized by constructing the function call graph of the source code. Based on the vulnerable function, the imported function and the second call graph, it is determined whether the vulnerable function is reachable in the software to be detected. The method of the present application makes it possible to analyze the vulnerability reachability of binary open source components, effectively reduces the probability of false positives of vulnerabilities, and greatly reduces the time cost of technicians to repair vulnerabilities.

[0063] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario and completed by multiple devices cooperating with each other. In the case of such a distributed scenario, one of the multiple devices can only perform one or more steps in the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the described method.

[0064] It should be noted that the above describes some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0065] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a vulnerability reachability analysis device for a binary mode open source component.

[0066] refer to Figure 3 , the vulnerability reachability analysis device of the binary mode open source component comprises: An identification module 302 is configured to determine a target open source component used in the software to be detected in binary form, and identify version information of the target open source component; The query module 304 is configured to determine a target vulnerability included in the target open source component in a vulnerability query database according to the identifier of the target open source component and the version information, and extract a vulnerability function of the target vulnerability according to the data information of the target vulnerability; A first generating module 306 is configured to extract the calling relationship between the entry program of the software to be detected and the target open source component based on the target vulnerability, and generate a first calling graph by an aggregation method according to the calling relationship; An extraction module 308 is configured to extract, according to the first call graph, an import function in the software to be detected that is used to call the target open source software; The second generating module 310 is configured to determine the source code repository address of the target open source component included in the first call graph, obtain the source code of the target open source component from the source code repository address, and generate a second call graph based on the source code using a generating tool; The determination module 312 is configured to determine whether the vulnerable function is reachable in the software to be detected based on the vulnerable function, the imported function and the second call graph.

[0067] In some embodiments, the identification module 302 is configured to construct a mapping database between open source components and open source binary component files included in the open source components; According to the target open source binary component file called in the software to be detected, the target open source component corresponding to the target open source binary component file is queried in the mapping database to determine.

[0068] In some embodiments, the identification module 302 is configured to, in response to the version information not being identified according to the resource folder of the target open source component, perform identification according to the version string of the target open source component; in response to the version information not being identified according to the version string of the target open source component, perform identification according to the internal read-only string of the target open source component to determine the version information of the target open source component.

[0069] In some embodiments, the first generation module 306 is configured to determine, according to the target vulnerability, an entry program in the software to be detected that can call a target open source component containing the target vulnerability as a risk entry program; According to the risk entry program and the calling manner of the target open source component called by the software to be detected, the calling relationship between the risk entry program and the target open source component is extracted, and a first call graph is generated through an aggregation method according to the calling relationship.

[0070] In some embodiments, the calling relationship includes a first calling relationship and a second calling relationship; the first generating module 306 is configured to extract an import table from the risk entry program in response to the calling mode being an implicit link, and parse the import table to obtain the first calling relationship; In response to the calling mode being a display link, each function block in the risk entry program is disassembled, an identifier of a target open source component linked in each function block is extracted, and a second calling relationship is constructed.

[0071] In some embodiments, the extraction module 308 is configured to extract an import table of a risk entry program for calling the target open source component in response to the software to be detected calling the target open source component through an implicit link, and determine the import function according to the import table; In response to the software to be detected calling the target open source component through a display link, the risk entry program used to call the target open source component is decompiled to obtain a decompiled function block; the export function set of the target open source component is determined, and candidate third-party functions are determined from the decompiled function block according to a retrieval tool function, and the third-party functions included in the export function set are used as the import functions.

[0072] In some embodiments, before the second call graph is generated by a generation tool based on the source code, a removal module is further included, which is configured to remove source code that does not correspond to the version information from the source code.

[0073] In some embodiments, the determination module 312 is configured to anchor the position of the vulnerable function and the position of the imported function on the second call graph, and based on the position of the vulnerable function and the position of the imported function, determine whether the vulnerable function is reachable in the software to be detected through a depth-first traversal algorithm.

[0074] For the convenience of description, the above device is described in terms of functions divided into various modules. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0075] The device of the above embodiment is used to implement the vulnerability reachability analysis method of the corresponding binary mode open source component in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0076] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the vulnerability reachability analysis method for the binary mode open source component described in any of the above embodiments is implemented.

[0077] Figure 4 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other through the bus 1050 in the device.

[0078] The processor 1010 can be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0079] The memory 1020 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0080] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0081] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0082] The bus 1050 includes a path that transmits information between the various components of the device (eg, the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 ).

[0083] It should be noted that, although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040 and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

[0084] The electronic device of the above embodiment is used to implement the vulnerability reachability analysis method of the corresponding binary mode open source component in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be repeated here.

[0085] Based on the same inventive concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the vulnerability reachability analysis method of the binary mode open source component as described in any of the above embodiments.

[0086] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0087] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the vulnerability reachability analysis method of binary mode open source components as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0088] Based on the same concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a computer program product, including computer program instructions. When the computer program instructions are run on a computer, the computer executes the method described in any of the above embodiments, which has the beneficial effects of the corresponding method embodiments and will not be repeated here.

[0089] A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0090] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present application difficult to understand, the known power / ground connections to the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. In addition, the device may be shown in the form of a block diagram to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the details of the implementation of these block diagram devices are highly dependent on the platform on which the embodiments of the present application are to be implemented (that is, these details should be fully within the scope of understanding of those skilled in the art). Where specific details (e.g., circuits) are set forth to describe exemplary embodiments of the present application, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details or with changes in these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0091] Although the present application has been described in conjunction with specific embodiments of the present application, many alternatives, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the discussed embodiments.

[0092] The embodiments of the present application are intended to cover all such substitutions, modifications and variations that fall within the broad scope of the present application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the protection scope of the present application.

Claims

1. A vulnerability accessibility analysis method for binary mode open source components, characterized in that: include: Determine a target open source component used in the software to be detected in binary form, and identify version information of the target open source component; According to the identifier of the target open source component and the version information, determine the target vulnerability contained in the target open source component in a vulnerability query database, and extract the vulnerability function of the target vulnerability according to the data information of the target vulnerability; Based on the target vulnerability, extract the call relationship between the entry program of the software to be detected and the target open source component, and generate a first call graph through an aggregation method according to the call relationship; Extracting, according to the first call graph, an import function in the software to be detected that is used to call the target open source software; Determine a source code repository address of a target open source component included in the first call graph, obtain source code of the target open source component from the source code repository address, and generate a second call graph based on the source code using a generation tool; Based on the vulnerable function, the imported function and the second call graph, determine whether the vulnerable function is reachable in the software to be detected.

2. The method according to claim 1, characterized in that The target open source components used in the software to be detected in binary form are determined, including: Building a mapping database between open source components and open source binary component files included in the open source components; According to the target open source binary component file called in the software to be detected, the target open source component corresponding to the target open source binary component file is queried in the mapping database to determine.

3. The method according to claim 1, characterized in that The identifying the version information of the target open source component includes: In response to the version information not being identified according to the resource folder of the target open source component, identification is performed according to the version string of the target open source component; in response to the version information not being identified according to the version string of the target open source component, identification is performed according to an internal read-only string of the target open source component to determine the version information of the target open source component.

4. The method according to claim 1, characterized in that The extracting the calling relationship between the entry program of the software to be detected and the target open source component based on the target vulnerability, and generating a first calling graph by an aggregation method according to the calling relationship, comprises: According to the target vulnerability, determining an entry program in the software to be detected that can call a target open source component containing the target vulnerability as a risk entry program; According to the risk entry program and the calling manner of the target open source component called by the software to be detected, the calling relationship between the risk entry program and the target open source component is extracted, and a first call graph is generated through an aggregation method according to the calling relationship.

5. The method according to claim 4, characterized in that The calling relationship includes a first calling relationship and a second calling relationship; the extracting the calling relationship between the risk entry program and the target open source component according to the calling manner of the risk entry program and the software to be detected calling the target open source component includes: In response to the calling mode being an implicit link, extracting an import table from the risk entry program, and parsing the import table to obtain a first calling relationship; In response to the calling mode being a display link, each function block in the risk entry program is disassembled, an identifier of a target open source component linked in each function block is extracted, and a second calling relationship is constructed.

6. The method according to claim 1, characterized in that The extracting, according to the first call graph, an import function for calling the target open source software in the software to be detected includes: In response to the software to be detected calling the target open source component through an implicit link, extracting an import table of a risk entry program for calling the target open source component, and determining the import function according to the import table; In response to the software to be detected calling the target open source component through a display link, the risk entry program used to call the target open source component is decompiled to obtain a decompiled function block; the export function set of the target open source component is determined, and candidate third-party functions are determined from the decompiled function block according to a retrieval tool function, and the third-party functions included in the export function set are used as the import functions.

7. The method according to claim 1, characterized in that Before generating the second call graph using a generation tool based on the source code, the method further includes: The source code that does not correspond to the version information is removed from the source code.

8. The method according to claim 1, characterized in that Determining whether the vulnerable function is reachable in the software to be detected based on the vulnerable function, the imported function, and the second call graph includes: The position of the vulnerable function and the position of the imported function are anchored on the second call graph, and based on the position of the vulnerable function and the position of the imported function, a depth-first traversal algorithm is used to determine whether the vulnerable function is reachable in the software to be detected.

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

10. A non-transitory computer-readable storage medium storing computer instructions, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 8.

Images