Vulnerability Reachability Analysis Method for Binary Mode Open-Source Components and Related Devices

Abstract

The present application provides a vulnerability reachability analysis method for open source components in binary mode and related equipment, the method comprising: determining the target open source component used in the software to be detected in binary form, and identifying the version information of the target open source component. According to the identification and version information of the target open source component, the target vulnerability is determined in the vulnerability query database, and the vulnerability function of the target vulnerability is extracted; based on the target vulnerability, the calling relationship between the entry program of the software to be detected and the target open source component is extracted to generate a first call graph. According to the first call graph, the import function for calling the target open source component in the software to be detected is extracted. The source code repository address of the target open source component included in the first call graph is determined, the source code of the target open source component is obtained from the source code repository address, and a second call graph is generated. Based on the vulnerability function, the import function and the second call graph, it is determined whether the vulnerability function is reachable in the software to be detected.

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 binary mode open source components and related equipment. Background Art

[0002] With the rapid development of open source projects and increasingly fierce market competition, more and more commercial software is incorporating open source components to accelerate software development. This approach allows commercial software to be released to market more quickly, but it also introduces new challenges to the security of the entire software ecosystem. For example, the introduction of open source components can also introduce vulnerabilities. Due to the commercial nature of commercial software, the source code is often not available. Most commercial software uses open source components in binary form, which creates new challenges for 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 objectives, this application provides a vulnerability reachability analysis method for open source components in binary mode, including:

[0005] Determine the target open source component used in the binary form of the software to be detected, and identify the version information of the target open source component;

[0006] Determining a target vulnerability contained 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 extracting a vulnerability function of the target vulnerability according to the data information of the target vulnerability;

[0007] 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;

[0008] 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 component;

[0009] Determining a source code repository address of a target open source component included in the first call graph, obtaining source code of the target open source component from the source code repository address, and generating a second call graph based on the source code using a generation tool;

[0010] 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.

[0011] In some embodiments, determining the target open source component used in the binary form of the software to be detected includes:

[0012] Building a mapping database between open source components and open source binary component files included in the open source components;

[0013] 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.

[0014] In some embodiments, identifying the version information of the target open source component includes:

[0015] 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 the internal read-only string of the target open source component to determine the version information of the target open source component.

[0016] 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:

[0017] 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;

[0018] According to the risk entry program and the calling method of the target open source component 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 according to the calling relationship through an aggregation method.

[0019] 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 based on the calling manner in which the risk entry program and the software to be detected call the target open source component includes:

[0020] 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;

[0021] 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.

[0022] In some embodiments, extracting, based on the first call graph, an import function for calling the target open source component in the software to be detected includes:

[0023] 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;

[0024] 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.

[0025] In some embodiments, before generating the second call graph using a generation tool based on the source code, the method further includes:

[0026] The source code that does not correspond to the version information is removed from the source code.

[0027] 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:

[0028] 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.

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

[0030] 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 as described in the first aspect.

[0031] As can be seen from the above, the present application provides a vulnerability accessibility analysis method for binary open source components and related equipment. The method includes: determining a target open source component used in binary software to be tested, identifying the version information of the target open source component, and realizing rapid identification of the target open source component. Based on the identification and version information of the target open source component, determining the target vulnerability contained in the target open source component in a vulnerability query database, and extracting the vulnerability function of the target vulnerability based on the data information of the target vulnerability; based on the target vulnerability, extracting the call relationship between the entry program of the software to be tested and the target open source component, and generating a first call graph based on the call relationship through an aggregation method. The first call graph is a coarse-grained call relationship graph that shows the call relationship between the entry program and the target open source component. Based on the first call graph, the import function used to call the target open source component in the software to be tested is extracted. The source code repository 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 repository address, and a second call graph is generated based on the source code using a generation tool. Through the mapping relationship between source code and binary, the call graph of the binary open source component is indirectly constructed by constructing a 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 tested. The method of the present application makes it possible to analyze the vulnerability reachability of binary open source components, effectively reducing the probability of false positives and greatly reducing the time cost for technicians to fix vulnerabilities. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] Figure 1 This is a flowchart of a vulnerability reachability analysis method for an open source component in binary mode according to an embodiment of the present application;

[0034] Figure 2 A schematic diagram of performing vulnerability reachability analysis on Ansys software according to an embodiment of the present application;

[0035] Figure 3 This is 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;

[0036] 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

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

[0038] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should have the usual meanings understood by people with ordinary skills in the field to which this application belongs. The "first", "second" and similar words used in the embodiments of the present application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "comprise" and similar words mean that the elements or objects appearing before 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 may 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.

[0039] As described in the background, most commercial software incorporates open source components. Existing C / C++-based commercial software uses open source components in two main ways: first, the source code of the open source component is incorporated into 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. Due to the commercial nature of commercial software, the source code is often not available. Most commercial software uses open source components in binary form, which creates new challenges for software composition analysis (SCA) of commercial software. Furthermore, popular open source components often contain more vulnerabilities, posing a greater security threat to commercial software.

[0040] Vulnerability reachability analysis is currently in high demand within the cybersecurity community. Vulnerability reachability is a technical capability focused on reducing false negatives from SCA tools. This capability, based on vulnerability database information and specialized techniques, accurately locates vulnerable functions and outlines their transmission paths (within and between components). Ultimately, this significantly reduces SCA false positive rates, even to near zero.

[0041] Unlike proprietary software, open source components have low code coverage because developers often directly integrate components in binary form. This results in vulnerabilities in open source components being mostly unreachable, placing a significant burden on fixers. Therefore, a method to reduce false positives through vulnerability reachability analysis is needed.

[0042] In view of this, this application proposes a vulnerability reachability analysis method for open source components in binary mode to solve the problem that existing software component analysis tools are unable to perform vulnerability reachability analysis for open source components. In particular, there is a lack of effective analysis tools for binary format software.

[0043] For ease of understanding, the definitions of terms used in this application are introduced below:

[0044] 1. Risk source software: Risk source software, abbreviated as RSS. Commercial software may have many EXE files, all of which can be called source programs. An EXE program that calls a third-party open source component with a vulnerable function is a risk source program.

[0045] 2. Source function (SF). A risky entry point program typically calls only a small number of exported functions within a third-party open source component. For example, the risky entry point program acp_grpcserver.exe in ANSYS software only calls the uncompress and compress functions in the zlib1.dll component. These functions are the entry points for the zlib component in the risky entry point program acp_grpcserver.exe.

[0046] 3. Export function: Export function, abbreviated as EF. Third-party open source components will explicitly write the function API interface provided to the outside in the export table. Functions implemented internally in the function API are not exposed. Functions in the export table are exported functions.

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

[0048] This application provides a vulnerability accessibility analysis method for open source components in binary mode. Figure 1 , including the following steps:

[0049] 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.

[0050] Specifically, the software to be tested is binary software. Software component analysis is performed on the software to be tested. This involves analyzing the accessibility of vulnerabilities in third-party open source components used by the software to be tested. First, determine which third-party open source components are included in the software to be tested.

[0051] Furthermore, we identify the target open source components used in the binary form of the software to be tested, including:

[0052] Building a mapping database between open source components and open source binary component files included in the open source components;

[0053] 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.

[0054] 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 the 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, the open source component corresponding to the identifier of the open source binary component file is searched in the constructed mapping database as the target open source component.

[0055] Furthermore, identifying the version information of the target open source component includes:

[0056] 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 the internal read-only string of the target open source component to determine the version information of the target open source component.

[0057] Specifically, this embodiment identifies the version information of the target open source component based on different version identification methods according to actual circumstances. These different version identification methods include three methods: a resource folder identification method, a version string identification method, and an internal read-only string identification method. The three identification methods are ranked from fastest to slowest in terms of recognition efficiency: the resource folder identification method, the version string identification method, and the internal read-only string identification method. First, version information is identified using the resource folder identification method, which has the highest recognition efficiency. If the resource folder is not empty, the information in the resource folder is used as the version information. Exemplarily, the information in the resource folder is VS_VERSIONINFO. If no version information is identified using the resource folder identification method, the version string identification method is used, and the identified version string is used as the version information. Exemplarily, the version string is 1.0.0. If no version information is identified using the version string identification method, the internal read-only string identification method is used, and the identified internal read-only string is used as the version information. Exemplarily, the internal read-only string is the read-only string in the .rdata segment of a PE (Portable Executable) file. By adopting different version identification methods to identify version information step by step, the identification efficiency can be effectively improved.

[0058] Step 104: Determine a target vulnerability contained in the target open source component in a vulnerability query database based on the identifier of the target open source component and the version information, and extract a vulnerability function of the target vulnerability based on the data information of the target vulnerability.

[0059] Specifically, the vulnerability database records the vulnerabilities corresponding to each open source component, and for the same open source component, different versions have different corresponding 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.

[0060] 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 call graph through an aggregation method according to the calling relationship.

[0061] 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. It includes 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 tested, it is necessary to extract the calling relationship between the corresponding entry program and the target open source component based on 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.

[0062] 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:

[0063] 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;

[0064] According to the risk entry program and the calling method of the target open source component 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 according to the calling relationship through an aggregation method.

[0065] Specifically, the entry point program that calls the target open source component containing the target vulnerability is considered the risk entry point program. As previously mentioned, the software under test can call third-party components in two ways: implicitly and explicitly. Different calling methods require different methods for determining the calling relationship. Therefore, it is necessary to extract the calling relationship between the risk entry point program and the target open source component based on the risk entry point program and the calling method.

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

[0067] Furthermore, the calling relationship includes a first calling relationship and a second calling relationship; and extracting the calling relationship between the risk entry program and the target open source component based on the calling manner in which the risk entry program and the software to be detected call the target open source component includes:

[0068] 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;

[0069] 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.

[0070] Specifically, for implicit linking, the import table is extracted from the risk entry point program. The import table, also known as the input table or import function table, is an integral part of the PE file structure. The import table acts as the key between the EXE file and the DLL file. All imported function information is written into the import table. After the PE file is mapped into memory, Windows loads the corresponding DLL file. The EXE file uses the "import table" to locate the import functions in the corresponding DLL, thereby completing the normal operation of the program. This dynamic linking process is entirely dependent on the import table. Once the import table is determined, all imported functions can be identified from the import table. Based on the import functions, the corresponding target open source component can be found, and then the first call relationship between the risk entry point program and the target open source component can be determined.

[0071] For explicit linking, we used the Ghidra tool to disassemble each function block in the risk entry program. We then traversed each function block and extracted the names of the target open source components linked to by these explicit linking functions within each function block, for those that used the four dynamic link library loading functions: LoadLibraryA, LoadLibraryW, LoadLibraryExA, and LoadLibraryExW. This allowed us to construct a second call relationship between the risk entry program and the target open source component under the explicit linking.

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

[0073] Step 108: Extract the import function for calling the target open source component in the software to be detected according to the first call graph.

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

[0075] Furthermore, extracting, based on the first call graph, an import function for calling the target open source component in the software to be detected includes:

[0076] 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.

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

[0078] 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.

[0079] 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, a candidate third-party function called by a search tool function, such as the GetProcAddress function, is found in the function block. 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.

[0080] 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.

[0081] Specifically, the source code repository address of the target open source component included in the first call graph is determined by web crawling. For example, the source code repository address of the target open source component can be determined by mapping the target open source component's name to the component's GitHub source code repository address. The source code repository address can be used to locate the target open source component's open source repository, and the source code of the target open source component can be obtained from the open source repository.

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

[0083] Because the source code contains source code for different versions of the target open source component, this embodiment only needs to extract the source code for the corresponding version of the target open source component 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 that matches the version information can be retained, reducing the amount of subsequent data processing. For example, the source code repository can be cloned locally using the git clone command, and the version corresponding to the detected version information can be switched to using the git checkout command.

[0084] Afterwards, the Doxygen documentation tool is modified to generate a function call graph in dot format for the removed source code, also known as the second call graph. Furthermore, to further accelerate the generation of the second call graph, the visualization function in the Doxygen documentation tool can be optimized. Removing unnecessary visualization functions can further increase the generation rate of the second call graph.

[0085] 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 the json format to facilitate subsequent data processing.

[0086] 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.

[0087] 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.

[0088] 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:

[0089] 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.

[0090] Specifically, since the nodes on the second call graph are identified by function names, the location of the vulnerable function and its imports can be anchored based on their names. By using a depth-first traversal algorithm to determine path reachability, the transfer path of the vulnerable function is outlined, and either the shortest reachable path or all reachable paths can be extracted.

[0091] The following describes a method for analyzing vulnerability accessibility of open source components in binary mode provided by this application through specific embodiments.

[0092] The target open source binary component file for the Ansys software was determined to be zlib1.dll. Based on a mapping database between open source components and open source binary component files, the target open source component was determined to be zlib. By identifying the version information of the target open source component zlib, the version information was determined to be 1.2.13. Based on this version information, by querying the vulnerability database, the vulnerability number corresponding to the target open source component zlib was determined to be CVE-2023-45853, and the vulnerable function name was zipOpenNewFileInZip4_64. When extracting the call relationships, it was determined that 14 risk entry programs all called the target open source component zlib. Based on the call relationships, a first call graph was generated through aggregation. For example, one of the risk entry functions was ANSYS Inc\\ANSYSStudent\\v241\\ACP\\acp_grpcserver.exe. The set of imported functions extracted from the first call graph was ['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 generating a second call graph. The vulnerable function and each imported function are anchored in the second call graph, and a 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.

[0093] Based on steps 102 to 112 above, this embodiment provides a vulnerability reachability analysis method for binary open source components, including: determining a target open source component used in binary software to be tested, identifying the version information of the target open source component, and achieving rapid identification of the target open source component. Based on the identifier and version information of the target open source component, determining the target vulnerability contained in the target open source component in a vulnerability query database, and extracting the vulnerability function of the target vulnerability based on the data information of the target vulnerability. Based on the target vulnerability, extracting the call relationship between the entry program of the software to be tested and the target open source component, and generating a first call graph based on the call relationship using an aggregation method. The first call graph is a coarse-grained call relationship graph that shows the call relationship between the entry program and the target open source component. Based on the first call graph, extracting the import function used to call the target open source component in the software to be tested. Determining the source code repository address of the target open source component contained in the first call graph, obtaining the source code of the target open source component from the source code repository address, and generating a second call graph based on the source code using a generation tool. Through the mapping relationship between source code and binary, the call graph of the binary open source component is indirectly constructed by constructing a 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 tested. The method of the present application makes it possible to analyze the vulnerability reachability of binary open source components, effectively reducing the probability of false positives and greatly reducing the time cost for technicians to fix vulnerabilities.

[0094] 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 in a distributed scenario and performed by multiple devices working together. In such a distributed scenario, one of the multiple devices may only perform one or more steps of the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the method.

[0095] It should be noted that the above description is limited to some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in an order different from that described in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0096] 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 binary mode open source components.

[0097] refer to Figure 3 The vulnerability reachability analysis device for the binary mode open source component includes:

[0098] An identification module 302 is configured to determine a target open source component used in the binary form of the software to be detected, and identify version information of the target open source component;

[0099] A query module 304 is configured to determine a target vulnerability contained 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;

[0100] A first generating module 306 is configured to extract 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 generate a first call graph according to the call relationship through an aggregation method;

[0101] An extraction module 308 is configured to extract, based on the first call graph, an import function in the software to be detected that is used to call the target open source component;

[0102] The second generation 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 generation tool;

[0103] 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.

[0104] In some embodiments, the identification module 302 is configured to build a mapping database between open source components and open source binary component files included in the open source components;

[0105] 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.

[0106] 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.

[0107] In some embodiments, the first generating module 306 is configured to determine, based on 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;

[0108] According to the risk entry program and the calling method of the target open source component 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 according to the calling relationship through an aggregation method.

[0109] In some embodiments, the call relationship includes a first call relationship and a second call relationship; the first generating module 306 is configured to extract an import table from the risk entry program in response to the call mode being an implicit link, and parse the import table to obtain the first call relationship;

[0110] 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.

[0111] In some embodiments, the extraction module 308 is configured to, in response to the software to be detected calling the target open source component through an implicit link, extract an import table of a risk entry program for calling the target open source component, and determine the import function according to the import table;

[0112] 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.

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

[0114] 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.

[0115] For the convenience of description, the above devices are described as being divided into various modules according to their functions. Of course, when implementing this application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0116] 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.

[0117] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the program, it implements the vulnerability reachability analysis method of the binary mode open source component described in any of the above embodiments.

[0118] Figure 4 A more specific hardware structure diagram of an electronic device provided in this embodiment is shown. 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 communicatively connected to each other within the device via the bus 1050.

[0119] The processor 1010 can be implemented using 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.

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

[0121] The input / output interface 1030 is used to connect to input / output modules to enable information input and output. The input / output modules can be configured as components within the device (not shown) or externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, and various sensors. Output devices may include a display, speaker, vibrator, indicator light, and the like.

[0122] The communication interface 1040 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, Wi-Fi, Bluetooth, etc.).

[0123] The bus 1050 comprises a pathway for transmitting information between various components of the device, such as the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 .

[0124] 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 a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0125] 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.

[0126] 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.

[0127] The computer-readable media of this embodiment includes permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device.

[0128] 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.

[0129] Based on the same concept, corresponding to any of the above-mentioned embodiments, 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.

[0130] Those 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 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.

[0131] In addition, to simplify the description and discussion, and to avoid obscuring the understanding of the embodiments of the present application, well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided figures. Furthermore, devices may be shown in block diagram form to avoid obscuring the understanding of the embodiments of the present application, and this also takes into account the fact that the implementation details of these block diagram devices are highly dependent on the platform on which the embodiments of the present application will be implemented (i.e., these details should be fully understood by those skilled in the art). Where specific details (e.g., circuits) are set forth to describe the exemplary embodiments of the present application, it will be apparent to those skilled in the art that the embodiments of the present application can be implemented without these specific details or with variations therefrom. Therefore, these descriptions should be considered illustrative rather than restrictive.

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

[0133] 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 scope of protection of the present application.

Claims

1. A vulnerability accessibility analysis method for binary mode open source components, characterized by: include: Determine the target open source component used in the binary form of the software to be detected, and identify the version information of the target open source component; Determining a target vulnerability contained 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 extracting a vulnerability function of the target vulnerability according to the data information of the target vulnerability; 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 according to the call relationship by an aggregation method, including: 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; Extracting a calling relationship between the risk entry program and the target open source component based on the risk entry program and the calling manner of the target open source component by the software to be detected, and generating a first call graph based on the calling relationship by an aggregation method; 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 component; Determining a source code repository address of a target open source component included in the first call graph, obtaining source code of the target open source component from the source code repository address, and generating 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, it is determined whether the vulnerable function is reachable in the software to be detected.

2. The method according to claim 1, characterized in that Determining the target open source components 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.

3. The method according to claim 1, characterized in that The identifying 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 the 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, wherein 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 based on 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.

5. The method according to claim 1, wherein Extracting, based on the first call graph, an import function for calling the target open source component 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.

6. 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.

7. 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.

8. 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 7 is implemented.

9. 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 7.

Images