Vulnerability verification method, device, medium and product based on extractable compiled code

Abstract

This application discloses a vulnerability verification method, device, medium, and product based on compileable code extraction, relating to the field of code vulnerability detection. The method includes: when a vulnerability to be verified is detected in the source code, identifying function-level code containing the vulnerability, wherein the function-level code is code that compiles successfully and uses functions as the smallest unit; identifying statement-level code containing the vulnerability from the function-level code, wherein the statement-level code is code that compiles successfully and uses statements as the smallest unit; and performing vulnerability verification operations on the statement-level code using a predetermined dynamic vulnerability verification tool to determine whether the statement-level code contains a vulnerability, and using the determination result as the basis for judging whether the source code contains a vulnerability. This application improves the efficiency of code vulnerability verification.

Description

Technical Field

[0001] This application relates to the field of code vulnerability detection technology, and in particular to a vulnerability verification method, device, medium and product based on compileable code extraction. Background Technology

[0002] With the increasing frequency and complexity of cyberattacks, the importance of application vulnerability discovery is growing. Among common vulnerability discovery techniques, static analysis can perform vulnerability discovery without compiling and running the program, offering the advantage of fast detection speed, but it suffers from a high false positive rate.

[0003] Traditional dynamic symbolic execution methods have been proven to mitigate the high false positive rate of static analysis, but they suffer from path explosion and low execution efficiency, limiting their application in medium and large-scale software. KLEE, SYMCC, and SYMSAN, as compiler-based symbolic execution tools, primarily perform static instrumentation during compilation, unlike dynamic instrumentation-based tools. They rely less or almost no on dynamic instrumentation during vulnerability verification, thus exhibiting higher execution efficiency. Currently known dynamic vulnerability verification methods extract static slices of vulnerabilities for symbolic execution, reducing redundant coverage paths and mitigating path explosion. However, for certain static slices, existing compiler-based symbolic execution tools may not be efficient in verifying vulnerabilities. Summary of the Invention

[0004] The purpose of this application is to provide a vulnerability verification method, device, medium, and product based on compileable code extraction, so as to solve the problem of low vulnerability verification efficiency described in the background art.

[0005] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a vulnerability verification method based on compileable code extraction, including: When a vulnerability to be verified is detected in the source code, the function-level code containing the vulnerability to be verified is identified. The function-level code is code that compiles successfully and uses functions as the smallest unit. The statement-level code containing the vulnerability to be verified is determined from the function-level code, wherein the statement-level code is code that has been compiled and is the smallest unit of code. A predetermined dynamic vulnerability verification tool is used to perform vulnerability verification operations on the statement-level code to determine whether the statement-level code has vulnerabilities, and the determination result is used as the basis for judging whether the source code has vulnerabilities.

[0006] Optionally, "determining the function-level code containing the vulnerability to be verified" includes: When a vulnerability to be verified is found in the source code, multiple associated functions of the vulnerability to be verified are determined. Determine the distance between each of the associated functions and the vulnerability, and denot it as the first distance; According to the principle of the first distance from near to far, the multiple association functions are divided into multiple function-level scopes. The larger the number of layers, the farther away from the first distance of the vulnerability. Each function-level scope includes at least one association function. Starting from the first function scope, extract the code from the first function scope and compile it; When compilation succeeds, the scope of the first-level function is determined to be the function-level code. If compilation fails, the second-level function scope is obtained, and the first and second-level function scopes are compiled as a whole; this process is repeated until compilation succeeds, and the code corresponding to the successful compilation is used as the function-level code.

[0007] Optionally, the "determining multiple correlation functions of the vulnerability to be verified" includes: Determine the location of the vulnerability to be verified, and record it as the vulnerability location; Based on the location of the vulnerability, the function containing the vulnerability tracing statement is taken as the function directly associated with the vulnerability; Static analysis is performed on the direct correlation function to determine the indirect correlation function.

[0008] Optionally, the step of "determining the distance between each of the associated functions and the vulnerability, denoted as the first distance" includes: Perform static semantic analysis on each statement in the function-level code to obtain the semantic features of each statement in the function-level code; The second distance between the statement and the vulnerability is determined based on the semantic features of each statement; According to the principle of the second distance from near to far, the statements included in the function-level code are divided into multiple layers of statement-level scopes. The larger the layer, the farther away it is from the second distance of the vulnerability. Each layer of statement-level scope includes at least one statement corresponding to the second distance. Starting from the first level of statement scope, extract the code from the first level of statement scope and compile it; When compilation succeeds, the first-level statement scope is determined to be the statement-level code; If compilation fails, the second-level statement scope is obtained, and the first and second-level statement scopes are compiled as a whole; this process is repeated until compilation succeeds, and the code corresponding to the successful compilation is used as the statement-level code.

[0009] Optionally, the step of "determining the second distance between the statement and the vulnerability based on the semantic features of each statement" includes: For each statement, analyze its semantic features to determine the propagation rules from the vulnerability to the statement. Based on the propagation rules, a second distance to the statement is determined using a predetermined model.

[0010] Optionally, the predetermined model is the following formula: d(B)=min((1+d(A[1]))*w[1], (1+d(A[2]))*w[2],..., (1+d(A[k]))*w[k]) Where B represents the next round of related propagation statement; d(B) represents the second distance between statement B and the vulnerability; The min function takes the minimum value among multiple parameter values; A[k] represents the Kth propagation initiation statement; d(A[k]) represents the second distance from A[k]; w[k] represents the propagation weight of the Kth association propagation.

[0011] Optionally, the program semantic static analysis includes: control flow analysis, data flow analysis, function call analysis, and constant propagation.

[0012] In a second aspect, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described in any one of the first aspects above.

[0013] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0014] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0015] According to the specific embodiments provided in this application, the following technical effects are disclosed: The vulnerability verification method based on compileable code extraction provided in this application first identifies the function-level code containing the vulnerability when determining the vulnerability to be verified; then, it identifies the statement-level code containing the vulnerability from the function-level code; and then uses a dynamic vulnerability verification tool to detect whether the statement-level code has a vulnerability. If the statement-level code has a vulnerability, it is determined that the source code has a vulnerability; if the statement-level code does not have a vulnerability, it is determined that the source code does not have the vulnerability to be verified. Compared with the prior art of manually verifying text-level vulnerabilities, this application reduces the code to be verified to statement-level code during the vulnerability verification process, thereby improving the efficiency of vulnerability verification. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is an application environment diagram of a vulnerability verification method based on compileable code extraction in one embodiment of this application; Figure 2 A flowchart illustrating a vulnerability verification method based on compileable code extraction, provided as an embodiment of this application; Figure 3 This application provides a flowchart illustrating a method for determining function-level code according to an embodiment of the present application. Figure 4 A flowchart illustrating a method for determining vulnerability-related functions according to an embodiment of this application; Figure 5 A flowchart illustrating a method for determining statement-level code according to an embodiment of this application; Figure 6 A flowchart illustrating a method for determining a second distance according to an embodiment of this application; Figure 7 A schematic diagram of a function-level scope provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0019] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the contents of this application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] The vulnerability verification method based on compileable code extraction provided in this application can be applied to, for example... Figure 1 In the application environment shown, the application environment includes a terminal and a server. The terminal communicates with the server via a network. A data storage system can store the data that the server needs to process. The data storage system can be set up independently, integrated into the server, or located in the cloud or on another server. The terminal can send the source code of the vulnerability to be verified to the server. After receiving the source code, the server can store it and retrieve it from the storage location when processing is needed, or it can execute the processing task while storing the source code. The server can then provide feedback on the vulnerability verification results obtained from the source code to the terminal. Furthermore, in some embodiments, the vulnerability verification method based on compileable code extraction can also be implemented independently by the server or the terminal. For example, the terminal can directly process the source code of the vulnerability to be verified, or the server can retrieve the source code of the vulnerability to be verified from the data storage system and perform verification processing on the source code.

[0021] The terminals can be, but are not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. Servers can be implemented using independent servers, server clusters composed of multiple servers, or cloud servers.

[0022] In one exemplary embodiment, see Figure 2 As shown, a vulnerability verification method based on compileable code extraction is provided. This method is executed by a computer device, specifically a terminal or server, or both. In this embodiment, the method is applied to... Figure 1 Taking the server in the example, the following steps 101 to 103 are used as an example: Step 101: When a vulnerability to be verified is detected in the source code, the function-level code containing the vulnerability to be verified is identified. The function-level code is code that is compiled successfully with functions as the smallest unit. For source code, static analysis tools can be used to scan it to determine if any vulnerabilities exist. However, since the results of static analysis tools are not always accurate and may contain errors, the scan does not necessarily identify a vulnerability. Further verification is needed to confirm whether a vulnerability truly exists. Therefore, subsequent steps are required to confirm its existence.

[0023] Furthermore, after scanning the source code, the static analysis tool will generate vulnerability reports. The vulnerability reports will record whether there are vulnerabilities in the source code and provide vulnerability information, including the file where the vulnerability is located, the line number, the vulnerability description, and vulnerability tracking.

[0024] Function-level code may include one function or multiple function codes.

[0025] Step 102: Identify the statement-level code containing the vulnerability to be verified from the function-level code. The statement-level code is code that has been compiled and is the smallest unit of code. Furthermore, those skilled in the art will know that a function code contains multiple statement codes, so statement-level code is a part of function-level code. Step 102 limits the function-level code to selecting compileable statement-level code from the function-level code.

[0026] In step 101, function-level code has already been identified. Therefore, when identifying statement-level code, the focus is on function-level code; it cannot exceed this level. This narrows the scope of subsequent static semantic analysis in the statement-level code extraction stage, thus improving the efficiency of statement-level code extraction. Therefore, starting with the function level avoids introducing irrelevant functions, narrows the verification scope, and improves vulnerability verification efficiency. Processing statement-level code first would introduce a large number of irrelevant functions, increasing the time and complexity of statement-level extraction and making subsequent compilation and verification stages more difficult.

[0027] Step 103: Use a predetermined dynamic vulnerability verification tool to perform vulnerability verification on the statement-level code to determine whether the statement-level code has vulnerabilities, and use the determination result as the basis for judging whether the source code has vulnerabilities.

[0028] Since statement-level code is part of the source code, a vulnerability in statement-level code indicates a vulnerability in the source code; conversely, a vulnerability in statement-level code indicates that the vulnerability to be verified does not exist in the source code.

[0029] The vulnerability verification method based on compileable code extraction provided in this application first identifies the function-level code containing the vulnerability when determining the vulnerability to be verified; then, it identifies the statement-level code containing the vulnerability from the function-level code; and then uses a dynamic vulnerability verification tool to detect whether the statement-level code has a vulnerability. If the statement-level code has a vulnerability, it is determined that the source code has a vulnerability; if the statement-level code does not have a vulnerability, it is determined that the source code does not have the vulnerability to be verified. Compared with the prior art of manually verifying text-level vulnerabilities, this application reduces the code to be verified to statement-level code during the vulnerability verification process, thereby improving the efficiency of vulnerability verification.

[0030] Furthermore, it should be noted that KLEE, SYMCC, and SYMSAN, as compilation-based symbolic execution technologies, have higher execution efficiency compared to dynamic instrumentation-based symbolic execution technologies. Typically, during execution, static code slices containing vulnerabilities need to be extracted. However, these extracted static slices may lack necessary compilation information, such as dependencies, missing functions or statements during code execution, which would prevent the use of the aforementioned compiled symbolic execution tools for verification. This application, however, performs function-level and statement-level compilation on the extracted code slices, thus enabling the use of compiled symbolic execution technologies such as KLEE, SYMCC, and SYMSAN to verify the vulnerable code.

[0031] Furthermore, before using static analysis tools to scan the source code under test, it is necessary to preprocess the source code. Preprocessing includes: parsing all compilation units, performing macro substitutions, recording all header files, functions, classes / structures, global variables, and other information, and using all the results of the preprocessing to build a compilation information database. Therefore, the compilation information database stores all the preprocessed content so that it can be retrieved promptly when needed.

[0032] Specifically, static analysis of the tested project involves macro replacement for macro expansion nodes in each compilation unit.

[0033] The header file dependencies of all files are parsed, and the paths of the dependent header files are stored in the compilation information database.

[0034] The dependencies of functions on classes, structures, global variables, etc., are resolved and stored in the compilation information database.

[0035] The functions, classes, structures, global variables, templates, functors, etc. in the file are encapsulated into units with attributes such as code and file path, and stored in the compilation information database.

[0036] Pre-compile the project under test to verify the integrity of the project's compilation information. If compilation fails, check and update the project code to confirm that the project can be compiled successfully.

[0037] Optionally, see Figure 3 In another exemplary embodiment of this application, step 101 includes the following steps 201 to 206: Step 201: When a vulnerability to be verified is detected in the source code, determine multiple associated functions of the vulnerability to be verified. The associated function is a function that is related to the vulnerability. For example, if the vulnerability appears in statement a, and a function A includes statement a, then function A is the associated function of the vulnerability.

[0038] Step 202: Determine the distance between each of the associated functions and the vulnerability, denoted as the first distance; The magnitude of the first distance represents the closeness of the relationship between the function and the vulnerability. The larger the first distance, the further apart the relationship between the associated function and the vulnerability, and the greater the number of layers of function-level scope.

[0039] For example, continuing with the above case, there is also a function B that calls function A. In this case, the distance of function B is greater than the distance of function A.

[0040] Step 203: According to the principle of the first distance from near to far, the multiple association functions are divided into multiple function-level scopes. The larger the number of layers, the farther away from the first distance of the vulnerability. Each function-level scope includes at least one association function. A function-level scope may include one or more association functions corresponding to the first distance. Furthermore, an association function corresponding to the first distance may be one or more association functions.

[0041] Furthermore, information about functions at each scope level is recorded in the compiler information database so that it can be retrieved promptly when needed. This function information includes: header files the function depends on, global variables, structures, etc.

[0042] Regarding the selection of the scope depth K, when K is set to the maximum correlation distance L, the compilation and verification steps need to be executed L times. When L is large, it is difficult to complete the process within a limited time. When K is set to 1, all related functions are extracted as the vulnerability code set. However, since some function calls do not affect vulnerability verification, K=1 is prone to introducing functions irrelevant to vulnerability verification. In practice, the selection of K is a compromise based on the project situation, balancing the efficiency of compilation and verification with the accuracy of function extraction.

[0043] Step 204: Starting from the first-level function scope, extract the code from the first-level function scope and compile it; Of course, before compilation, the header files, global variables, structures, etc. that the function depends on must be retrieved from the database and added to the code in order to achieve compilation.

[0044] Step 205: When compilation is successful, determine that the first-level function scope is the function-level code; Step 206: When compilation fails, obtain the second-level function scope and compile the first and second-level function scopes as a whole; repeat this process until compilation succeeds, and use the code corresponding to the successful compilation as the function-level code.

[0045] In this process, step 206 refers to obtaining the next layer and recompiling when the compilation fails.

[0046] Compilation starts from the first function scope, that is, from the closest function scope. When compilation is successful, subsequent large function scopes are no longer compiled, thus finding the function code containing the fewest functions, improving compilation efficiency, and consequently improving the efficiency of the entire vulnerability verification.

[0047] For example, suppose there are four layers. If the first and second layers fail to compile, then the third layer is obtained. The first to third layers are compiled as a whole. If they succeed, then the fourth layer will not be compiled.

[0048] For example, using C / C++ as an example, the extracted function-level code is compiled and verified. The compilation and verification steps are divided into preprocessing, compilation, assembly, and linking. If the above compilation process fails, the function-level code and related content of the next level function scope are extracted.

[0049] Specifically, based on the extracted function-level code, the path of the referenced header files is queried from the compilation information database. One specific query implementation, for a key-value storage database, stores function header file information in the following format: key = <function name, path> value = {a collection of header file paths} If the extracted function file name is fname and the path is path, it can be generated using the key=<fname,path> The system retrieves the corresponding value from the database to obtain a set of header file paths, named `paths`. For each header file path in the set, the corresponding header file is copied from the project under test and added to the vulnerable code set.

[0050] Repeat the above compilation verification and function-level scope extraction steps until compilation succeeds. Finally, the extracted function-level vulnerability code is obtained.

[0051] Optionally, see Figure 4 In another exemplary embodiment of this application, step 201 includes the following steps 301-303: Step 301: Determine the location of the vulnerability to be verified, and record it as the vulnerability location; Based on the vulnerability report scanned by the static analysis tool, obtain vulnerability information, including the location of the vulnerability, such as the file where the vulnerability is located, the line number, the vulnerability description, and vulnerability tracking.

[0052] For example, the test result report given by the static analysis tool: Vulnerability Description: The value [text] from the outside world is output on line (10). If it contains metacharacters or values ​​from the source code, the web browser will execute the code as if displaying an HTTP response. An attacker can create a malicious URL and then use email or social engineering to trick the victim into visiting the link of this URL, thereby bringing malicious content to the victim's computer.

[0053] Vulnerability Tracking 1: The statement [request.getParameter("text")] is executed on line (7); Vulnerability tracking location: file GB34944_08_01.java, line (7); Vulnerability tracking location: file IOComponent.java, line (7); Vulnerability Tracking 2: In line (7), the string is concatenated to [text], where the variable [request.getParameter("text")] may come from external input parameters; Vulnerability tracking location: file IOComponet.java, line (7); Vulnerability Tracking 3: The statement [out.write(text)] is executed on line (10), where the variable [text] may be passed or come from external input parameters; Vulnerability tracking location: file IOComponet.java, line (10); Based on the vulnerability description and vulnerability tracking, the function containing the vulnerable statement can be determined. This vulnerability tracking is typically generated using techniques such as value flow analysis and taint analysis within static analysis.

[0054] Step 302: Based on the location of the vulnerability, the function containing the vulnerability tracing statement is taken as the function directly associated with the vulnerability; Vulnerability tracking statements include all statements from the start point to the end point of vulnerability tracking. The start and end points of vulnerability tracking determine the detection scope of static scanning tools. For relevant content, please refer to relevant documents in this field, which will not be elaborated here.

[0055] The directly associated function can be one or more.

[0056] Furthermore, the scope of directly associated functions is considered to be the first closest associated function, denoted as the first-level function scope.

[0057] Step 303: Perform static analysis on the direct correlation function to determine the indirect correlation function.

[0058] Each direct association function may have one or more indirect association functions.

[0059] In step 303, "static analysis" refers to the analysis of relationships between functions, such as function call analysis.

[0060] Based on this direct correlation function, a vulnerability correlation variable table is constructed. Function call analysis is performed on the direct correlation functions in the vulnerability correlation variable table to obtain the indirect correlation functions.

[0061] For example, a vulnerability association table in JSON format is provided, containing information such as variable ID, name, type, function, code location, context information, referenced variables, and taint status. { "variable_ID": "v00003", "variable_name": "userInput", "variable_type": "parameter", "direct_func": "parseData", "direct_func_location": "Example.java:40", "usage_context": "condition_check", "related_functions": ["validateInput"], "indirect_funcs": ["sanitizeInput", "storeData"], "ref_vars": ["v00007"] "taint_status": "tainted", Notes: "XSS" } ] Functions that are related to the vulnerability, other than those directly associated with the vulnerability, are called indirectly associated functions.

[0062] Specifically, see Figure 7 For the vulnerability-directly associated function f1, function call analysis reveals that f1 calls functions f2 and f3, f2 calls f4, and f3 calls f5. Using breadth-first search, the associated functions include f2, f3, f4, and f5. Functions with an association distance of 1 are f2 and f3, and functions with an association distance of 2 are f4 and f5. Following the association distance calculation rules, assuming the maximum association distance is L, and dividing the scope into K layers, the difference in association distance between functions within each function scope is within ⌈L / K⌉.

[0063] Based on the aforementioned scope division of vulnerability functions, indirectly related functions are extracted layer by layer. After extracting all indirectly related functions in the current scope, the variable information in the extracted functions is analyzed. The vulnerability-related variable table is updated based on the analysis results, including adding new variable information and updating the attributes of original variables.

[0064] Specifically, for called functions that have not yet been extracted from the current function scope—for example, if the scoped function code contains the statement `x = y + funcZ()`, where the function `funcZ()` is not in the scope and has not yet been extracted—the vulnerability-related variable table is consulted to determine whether to extract the called function. If it is confirmed that the called function involves modifying the pointer or reference of the variable `x`, or assigning a return value, the called function `funcZ()` is directly extracted as an indirectly related function in the current scope. If it is confirmed that the called function is unrelated to the variable, an empty function with a default specific return type is generated based on the return type of the called function, such as `intfuncZ(){return 1;}`, resolving compilation errors caused by the lack of a called function.

[0065] Direct association functions and indirect association functions are collectively referred to as association functions.

[0066] Optionally, see Figure 5 In another exemplary embodiment of this application, step 202 includes the following steps 401-406: Step 401: Perform static semantic analysis on each statement in the function-level code to obtain the semantic features of each statement in the function-level code; Optionally, in another exemplary embodiment of this application, the program semantic static analysis includes: control flow analysis, data flow analysis, function call analysis, and constant propagation.

[0067] Furthermore, this step of function call analysis includes pointer pointing analysis.

[0068] Step 402: Determine the second distance between the statement and the vulnerability based on the semantic features of each statement; The magnitude of the second distance represents how close the function is to the vulnerability; the larger the second distance, the further the statement is from the vulnerability.

[0069] The second distance can be calculated using the control flow-statement association distance.

[0070] Step 403: According to the principle of the second distance from near to far, the statements included in the function-level code are divided into multiple layers of statement-level scopes. The larger the layer, the farther away it is from the second distance of the vulnerability. Each layer of statement-level scope includes at least one statement corresponding to the second distance. The second distance indicates the degree of relationship between the statement and the vulnerability. The closer the second distance, the closer the relationship; the farther the second distance, the farther the relationship.

[0071] A statement-level scope may include one statement corresponding to a second distance, or it may include multiple statements corresponding to second distances. Furthermore, a second distance may correspond to one statement, or it may correspond to multiple statements.

[0072] For example, some statements in the function-level code are far from the vulnerability, while others are close. Further, the statement closest to the vulnerability in the vulnerability flow tracing path is considered a directly related statement and is denoted as the first-level statement scope. Based on the statement association propagation rules, a second distance is calculated for each statement, and the scope is divided into K levels from closest to furthest based on the second distance.

[0073] The second distance is calculated according to the above rules. After the second distance calculation stops, the return statement of a function that has not been added to the statement-level scope is taken as the last level of scope to avoid compilation failures caused by missing function return statements in the control flow branch. For return statements with undefined variable return values, the constant propagation result of the variable in the return statement is obtained. If it is determined to be a constant, the constant value is used to fill the return value; otherwise, the calculation of the association distance and the extraction of statements continue to ascend layer by layer from the return statement.

[0074] Information about each statement-level scope is recorded for subsequent statement-level code extraction and compilation.

[0075] Step 404: Starting from the first-level statement scope, extract the code from the first-level statement scope and compile it; Step 405: When compilation is successful, determine that the first-level statement scope is the statement-level code; Step 406: When compilation fails, obtain the second-level statement scope and compile the first and second-level statement scopes as a whole; repeat this process until compilation succeeds, and use the code corresponding to the successful compilation as the statement-level code.

[0076] This process refers to obtaining the next layer and recompiling when compilation fails, repeating this process until compilation succeeds.

[0077] Compilation starts from the first statement-level scope, which is the second closest statement-level scope. When compilation is successful, subsequent large statement-level scopes are no longer compiled, thus finding the statement-level code with the fewest statements, improving compilation efficiency, and consequently improving the efficiency of the entire vulnerability verification process.

[0078] Optionally, see Figure 6 In another exemplary embodiment of this application, step 402 includes the following steps 501 and 502: Step 501: For each statement, analyze its semantic features and determine the propagation rules from the vulnerability to the statement. Step 502: Based on the propagation rules, determine the second distance of the statement using a predetermined model.

[0079] The propagation rules are used to qualitatively analyze whether there is a connection between statements, while the predefined model is used to quantitatively analyze the degree of connection between statements. Qualitative analysis is performed first, followed by quantitative analysis.

[0080] Optionally, the predetermined model is the following formula: d(B)=min((1+d(A[1]))*w[1], (1+d(A[2]))*w[2],..., (1+d(A[k]))*w[k]) Where B represents the next round of related propagation statement; d(B) represents the second distance between statement B and the vulnerability; The min function takes the minimum value among multiple parameter values; A[k] represents the Kth propagation initiation statement; d(A[k]) represents the second distance from A[k]; w[k] represents the propagation weight of the Kth association propagation.

[0081] The model was obtained through the following process: Locate the vulnerability flow tracing path, identify the corresponding statements in the vulnerability flow tracing path as directly associated statements of the vulnerability, mark the association distance as 0, and calculate the statement association distance according to the statement association propagation rules.

[0082] Specifically, for a propagation rule, let the propagation weight w, and let the current propagation starting statement be A and the next propagation statement be B. Then the propagation distance d(A) of the starting statement A and the propagation distance d(B) of the next propagation statement B have the following relationship: d(B) = (1+d(A))*w The correlation propagation weight w>=1, and the smaller w is, the higher the degree of correlation between the statements; For k association propagation rules, let the association propagation weights be w[1], w[2], ..., w[k], and let the propagation start statements be A[1], A[2], ..., A[k], and they have the same association propagation statement B, then there are multiple start statements. The association distance d(A[i]) of A[i] and the association distance d(B) of the next round of propagation statement B have the relationship described in the above-mentioned predetermined model.

[0083] Furthermore, the statement association propagation rules include, but are not limited to, the following four: Declaration / Assignment Statements: Based on the data flow analysis results, the current declaration / assignment statement is forwarded to the next statement in the statement that uses the variable; Variable usage statement: Based on the data flow analysis results, the current variable usage statement is propagated to the previous variable definition statement; Function call statement: Based on the analysis results of the function call, the current function call statement is forwarded to the formal parameter declaration statement of the called function; Compound statements: These are calculated by splitting the statement into the above statements.

[0084] Furthermore, after identifying the statement-level code, the following methods can be used to complete vulnerability verification: First, add a program startup main function to the statement-level code, create parameter inputs based on the vulnerability entry function, add vulnerability function call statements, and obtain new code for verifying the vulnerability.

[0085] Second, compile the new code used to verify the vulnerability and use a dynamic symbolic execution tool to verify the vulnerability.

[0086] Dynamic symbolic execution tools can employ compiled symbolic execution tools.

[0087] For example, taking a compileable vulnerability code slice as an example, the following is a preprocessed function code snippet from an engineering project: static void func_test_call_1(child_process *cp, int reason){ if (62 == reason&&!check_completion(cp)) { printf("cp->id=%u\n", cp->id); return; } } The following detection result report is provided after static tool scanning: Vulnerability description: The [check_completion] method is called on line (2) to release the memory pointed to by [cp], and the statement [printf("cp->id=%u\n", cp->id)] on line (3) uses the released memory; Vulnerability location: file func_test.cpp, line (3); Vulnerability Tracking 1: Line (2) calls the [check_completion] method; Vulnerability tracking location: file func_test.cpp, line (2); Vulnerability Tracking 2: The [destroy_job] method is called on line (5); Vulnerability Tracking Location: file func_check.cpp, line (5); Vulnerability Tracking 3: The [free] method is called on line (6) to release memory; Vulnerability Tracking Location: file task.cpp, line (6); Vulnerability Tracking 4: The statement [printf("cp->id=%u\n", cp->id)] in line (3) uses freed memory; Vulnerability Tracking Location: file CookieService.java, line (7); Based on the aforementioned detection report, the directly associated functions of the vulnerability are identified as func_test_call_1, check_completion, and destroy_job. Pointer analysis and function call analysis were performed on the function code. Starting with the directly associated functions, the association distance between the vulnerable functions was calculated. The maximum association distance was found to be L=14. With K=7 selected, ⌈L / K⌉=2, meaning that every two function calls are considered as one function scope. Figure 7 As shown.

[0088] During the function-level extraction and compilation verification phase, after the second-level function scope extraction, the program compiles successfully.

[0089] Calculate the second distance. For the vulnerability-directly associated statement `check_completion(cp)` (function code below), its association distance is 0. Starting from this call point, set the propagation weight `w` of each association calculation rule to 1. Based on the statement association calculation rules, calculate the association distance of each statement, with the following results: Second distance 1: child_process *cp Obtained through the propagation rules of function call statements; Second distance 2: if(!cp), if(result == cp->ei->pid), cp->ret = status, destroy_job(cp) Obtained through the propagation rules of declaration / assignment statements; Second distance 3: int result = 0, status = 0 Obtained through variable propagation rules using statements; Second distance 4: scanf("%d",&result), scanf("%d",&status), do{}while(result<0&&errno == ECHILD), if(result<0&&errno == ECHILD), return -errno Obtained through the propagation rules of declaration / assignment statements; Second distance 5: error = 0 Obtained through variable propagation rules using statements; Second distance 6: return 1, return 0 Add / populate rules to the return statement to get Non-associative statement: int exception = 1 For hierarchical extraction of control flow at the basic block level, the calculated maximum association distance L=15, K=6, ⌈L / K⌉=3, and every three association propagation statements constitute one scope. For the function check_completion, the vulnerability control flow statements are classified into scopes based on the association distance using the following code statement comments: static int check_completion(child_process *cp) / / Scope 1 { int result = 0, status = 0; / / Scope 1 int exception = 1; if (!cp ) { / / Scope 1 return exception; / / Scope 2 } do { errno = 0; / / Scope 2 scanf("%d",&result); / / Scope 2 scanf("%d",&status); / / Scope 2 } while (result<0&&errno == EINTR); / / Scope 2 if (result == cp->ei->pid / / Scope 1) || (result<0&&errno == ECHILD)) { / / Scope 2 cp->ret = status; / / Scope 1 destroy_job(cp); / / Scope 1 return 0; / / Scope 2 } return -errno; / / scope 2 } The vulnerability control flow statements, as defined above, are extracted hierarchically. After each extraction, the resulting vulnerability code set is compiled and verified. After extraction at the fourth level of scope, the vulnerability control flow statement code set compiles successfully.

[0090] Add the following program to start the main method: static int main(int argc, char **argv) { output_param1(); output_param2(); child_process param1 = input_param1(argv); int param2 = input_param2(argv); func_test_call_1(param1, param2); } The child_process pointer is used to parse the structure attributes, generate the prompt output text, and generate the child_process structure object based on the user input.

[0091] Finally, the vulnerability code set extracted in the above steps is compiled and dynamically symbolically executed and verified using a compiled symbolic execution tool such as SYMCC.

[0092] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram can be found in [reference needed]. Figure 8 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data related to the source code of the vulnerability to be verified. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it can implement a vulnerability verification method based on compileable code extraction.

[0093] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0094] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0095] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0096] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0097] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data that have been agreed to by the user or have been fully agreed to by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0098] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. In the embodiments provided in this application, any reference to memory, database, or other media can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0099] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic units, data processing logic units, etc., and are not limited to these.

[0100] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0101] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A vulnerability verification method based on compileable code extraction, characterized in that, include: When a static analysis tool detects a vulnerability in the source code that needs to be verified, the function-level code containing the vulnerability is identified. The function-level code is code that compiles successfully and uses functions as the smallest unit. The statement-level code containing the vulnerability to be verified is determined from the function-level code, wherein the statement-level code is code that has been compiled and is the smallest unit of code. A predetermined dynamic vulnerability verification tool is used to perform vulnerability verification operations on the statement-level code to determine whether the statement-level code has vulnerabilities, and the determination result is used as the basis for judging whether the source code has vulnerabilities. The phrase "determining the function-level code containing the vulnerability to be verified" includes: When a vulnerability to be verified is found in the source code, multiple associated functions of the vulnerability to be verified are determined. Determine the distance between each of the associated functions and the vulnerability, and denot it as the first distance; According to the principle of the first distance from near to far, the multiple association functions are divided into multiple function-level scopes. The larger the number of layers, the farther away from the first distance of the vulnerability. Each function-level scope includes at least one association function. Starting from the first function scope, extract the code from the first function scope and compile it; When compilation succeeds, the scope of the first-level function is determined to be the function-level code. If compilation fails, the second-level function scope is obtained, and the first and second-level function scopes are compiled as a whole; this process is repeated until compilation succeeds, and the code corresponding to the successful compilation is used as the function-level code.

2. The vulnerability verification method based on compileable code extraction according to claim 1, characterized in that, The "determining multiple correlation functions of the vulnerability to be verified" includes: Determine the location of the vulnerability to be verified, and record it as the vulnerability location; Based on the location of the vulnerability, the function containing the vulnerability tracing statement is taken as the function directly associated with the vulnerability; Static analysis is performed on the direct correlation function to determine the indirect correlation function.

3. The vulnerability verification method based on compileable code extraction according to claim 1, characterized in that, The phrase "determining the distance between each of the associated functions and the vulnerability, denoted as the first distance" includes: Perform static semantic analysis on each statement in the function-level code to obtain the semantic features of each statement in the function-level code; The second distance between the statement and the vulnerability is determined based on the semantic features of each statement; According to the principle of the second distance from near to far, the statements included in the function-level code are divided into multiple layers of statement-level scopes. The larger the layer, the farther away it is from the second distance of the vulnerability. Each layer of statement-level scope includes at least one statement corresponding to the second distance. Starting from the first level of statement scope, extract the code from the first level of statement scope and compile it; When compilation succeeds, the first-level statement scope is determined to be the statement-level code; If compilation fails, the second-level statement scope is obtained, and the first and second-level statement scopes are compiled as a whole; this process is repeated until compilation succeeds, and the code corresponding to the successful compilation is used as the statement-level code.

4. The vulnerability verification method based on compileable code extraction according to claim 3, characterized in that, The phrase "determining the second distance between the statement and the vulnerability based on the semantic features of each statement" includes: For each statement, analyze its semantic features to determine the propagation rules from the vulnerability to the statement. Based on the propagation rules, a second distance to the statement is determined using a predetermined model.

5. The vulnerability verification method based on compileable code extraction according to claim 4, characterized in that, The predetermined model is as follows: d(B)=min((1+d(A[1])) w[1],(1+d(A[2])) w[2],...,(1+d(A[k])) w[k]) Where B represents the next round of related propagation statement; d(B) represents the second distance between statement B and the vulnerability; The min function takes the minimum value among multiple parameter values; A[k] represents the k-th propagation initiation statement; d(A[k]) represents the second distance from A[k]; w[k] represents the propagation weight of the associated propagation of the k-th propagation initiation statement.

6. The vulnerability verification method based on compileable code extraction according to claim 3, characterized in that, The program semantic static analysis includes: control flow analysis, data flow analysis, function call analysis, and constant propagation.

7. A computer device, comprising: A memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that the processor executes the computer program to implement the vulnerability verification method based on compileable code extraction as described in any one of claims 1-6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the vulnerability verification method based on compilable code extraction as described in any one of claims 1-6.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the vulnerability verification method based on compilable code extraction as described in any one of claims 1-6.

Images