A memory vulnerability detection method and its device, equipment and storage medium

Abstract

The embodiment of the present application provides a memory vulnerability detection method and its apparatus, device and storage medium, wherein the method comprises: performing syntax analysis on the acquired source program to be detected to generate an abstract syntax tree; extracting feature information of each node in the abstract syntax tree; determining a target node based on the feature information of each node; generating a pointer-related control flow graph based on the target node; determining the vulnerability node in the source program to be detected based on the pointer-related control flow graph and preset vulnerability detection rules; in this way, the detection accuracy and efficiency of memory vulnerability detection can be improved.

Description

Technical Field

[0001] The present application belongs to the field of computer technology and relates to, but is not limited to, a memory vulnerability detection method and its device, equipment and storage medium. Background Art

[0002] With the increasing demand for computer applications, the design and development of applications are becoming increasingly complex. The number of variables that developers deal with during program implementation has also increased significantly. In daily software development, some code that causes memory leaks will be introduced to a greater or lesser extent. Memory leak defects are hidden and cumulative, and are more difficult to detect than other memory access errors. Because memory leaks are caused by memory blocks not being released, they are omission defects rather than fault defects. In addition, memory leaks usually do not directly produce observable error symptoms, but gradually accumulate, reducing the overall performance of the system, and in extreme cases may cause the system to crash. Therefore, how to efficiently and accurately detect memory vulnerabilities is a technical problem that needs to be solved urgently. Summary of the invention

[0003] The embodiments of the present application provide a memory vulnerability detection method and its apparatus, device and storage medium, which can improve the detection accuracy and detection efficiency of memory vulnerability detection.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] The present invention provides a memory vulnerability detection method, which includes:

[0006] Perform syntax analysis on the acquired source program to be tested and generate an abstract syntax tree;

[0007] Extracting feature information of each node in the abstract syntax tree;

[0008] Determine the target node based on the characteristic information of each node;

[0009] Generate a pointer-related control flow graph based on the target node;

[0010] Based on the pointer-related control flow graph and preset vulnerability detection rules, vulnerability nodes in the source program to be detected are determined.

[0011] The embodiment of the present application provides a memory vulnerability detection device, the device comprising at least: a syntax analysis module, a feature extraction module, a first determination module, a first generation module and a second determination module, wherein:

[0012] The syntax analysis module is used to perform syntax analysis on the acquired source program to be detected and generate an abstract syntax tree;

[0013] The feature extraction module is used to extract feature information of each node in the abstract syntax tree;

[0014] The first determination module is used to determine the target node based on the characteristic information of each node;

[0015] The first generating module is used to generate a pointer-related control flow graph based on the target node;

[0016] The second determination module is used to determine the vulnerability node in the source program to be detected based on the pointer-related control flow graph and preset vulnerability detection rules.

[0017] The embodiment of the present application provides a memory vulnerability detection device, the memory vulnerability detection device comprising at least: a memory, a communication bus and a processor, wherein:

[0018] The memory is used to store a memory vulnerability detection program;

[0019] The communication bus is used to realize the connection and communication between the processor and the memory;

[0020] The processor is used to execute the memory vulnerability detection program stored in the memory to implement the steps of the memory vulnerability detection method provided in other embodiments.

[0021] An embodiment of the present application provides a storage medium, on which a memory vulnerability detection program is stored. When the memory vulnerability detection program is executed by a processor, the steps of the memory vulnerability detection method provided in other embodiments are implemented.

[0022] The embodiments of the present application provide a memory vulnerability detection method, apparatus, device and storage medium, wherein the acquired source program to be detected is firstly subjected to grammatical analysis to generate an abstract syntax tree; then, feature information of each node in the abstract syntax tree is extracted; based on the feature information of each node, a target node is determined, wherein the target node includes at least a pointer definition node; a pointer-related control flow graph is generated based on the target node; based on the pointer-related control flow graph and preset vulnerability detection rules, a vulnerability node with a memory leak in the source program to be detected is determined, thereby formally describing the features of the memory vulnerability based on PCFG, and abstracting the vulnerability judgment rules based on the formal description of the relevant vulnerability features, which can effectively improve the efficiency of memory-related vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A schematic diagram of an implementation flow of the memory vulnerability detection method according to an embodiment of the present application;

[0024] Figure 2 A schematic diagram of the implementation process of generating a pointer-related control flow graph for an embodiment of the present application;

[0025] Figure 3 This is another implementation flow diagram of the memory vulnerability detection method according to an embodiment of the present application;

[0026] Figure 4 A schematic diagram of an implementation framework of a memory vulnerability detection method provided in an embodiment of the present application;

[0027] Figure 5 This is a schematic diagram of the composition structure of the memory vulnerability detection device according to an embodiment of the present application;

[0028] Figure 6 This is a schematic diagram of the composition of the memory vulnerability detection device according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] In order to make the purpose, technical solution and advantages of the present application clearer, the specific technical solution of the present application will be further described in detail below in conjunction with the drawings in the embodiments of the present application. The following embodiments are used to illustrate the present application, but are not used to limit the scope of the present application.

[0030] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it can be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0031] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0033] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0034] 1) Memory vulnerability, also known as memory leak, refers to the situation where dynamically allocated memory units are no longer used but are not released.

[0035] 2) Vulnerability feature σ: σ(VulType) = {N, C}. Where VulType represents the vulnerability type, N represents the vulnerability-related danger point, and N = {N1, N2, ..., Ni}, i = 0, 1, 2, .... For the program Prog, all program statements containing the danger factor ξ are called vulnerability-related danger points N. C represents the vulnerability-related constraint, which represents the constraint relationship between the elements in the vulnerability-related danger point N. In the embodiment of the present application, C is defined as: C = C1||C2||C3||...||Cj||..., j = 0, 1, 2, ..., and Cj = BCj∧ACj, that is, the characteristics of a certain vulnerability may include multiple vulnerability-related constraints, and any vulnerability-related constraint Cj includes two parts: basic constraint BCj and additional constraint ACj. The basic constraint BCj represents the basic constraint conditions that must be met to generate the vulnerability, and the additional constraint ACj represents the additional constraint conditions that must be met to generate the vulnerability.

[0036] 3) Pointer related Control Flow Graph (PCFG): PCFG only contains pointer definition, pointer access, memory allocation and release, and related nodes to ensure the complete structure of the program, and each node in the graph has a characteristic attribute. PCFG = (N, E, Entry, Exit). N is the node set, n=(id,lnum,nextn_id,nf). Among them, id represents the number of node n in PCFG, lnum represents the line number of the current node in the source program, nextn_id represents the id of the next node in PCFG, and nf represents the node feature. E is an edge set, which is used to represent the pointing relationship between nodes, and each edge is an ordered node pair indicating that there may be a control flow relationship from node ni to node nj.<ni,nj> Entry is the entry node of PCFG, and Exit is the exit node of PCFG.

[0037] 4) Executable Path: In PCFG, Path =<n0,n1,n2,…,nm> is a statement sequence. If (ni-1, ni)∈E, where i=1, 2,…, m, then Path is called an executable path of PCFG.

[0038] 5) Data Dependence (DataDep): For any two nodes nx and ny on PCFG, if there is an executable path from node nx to node ny, there is a variable var defined in node nx and used in node ny, and variable var is not redefined anywhere else on the path from node nx to node ny, then node ny is said to be data dependent on node nx, denoted as DataDep(nx, ny, var).

[0039] 6) Successor relationship (Suc): For any two nodes nx and ny on PCFG, if there is an executable path from node nx to node ny, then node ny is called the successor node of node nx, denoted as Suc(nx, ny).

[0040] 7) Define pointer DPV(pv): DefPointerVariable(pv) is used to represent the pv declaration and definition of the pointer variable, which is abbreviated as DPV(pv) in the embodiment of the present application.

[0041] 8) Memory allocation function MMF(pv): MemoryMallocFunction(pv) is used to represent memory allocation for pointer variable pv, abbreviated as MMF(pv). Commonly used memory allocation related functions include: malloc, calloc and realloc in C language; new, new[] in C++ language.

[0042] 9) Memory release function MFF(pv): MemoryFreeFunction(pv) is used to release the memory pointed to by pointer pv, which is abbreviated as MFF(pv). Common memory release related functions include: free in C language, delete and delete[] in C++ language, etc. In the embodiment of the present application, the pair MMF(pv) / MFF(pv) is used to indicate that the allocation and release functions are matched. The pair indicates that the allocation and deallocation functions do not match.

[0043] 10) Use pointer UPV(pv): Use UsePointerVariable(pv) to indicate the use of pointer variable pv, abbreviated as UPV(pv).

[0044] 11) Operation inclusion relationship: Has(n, Operation / Function) indicates that the current statement n contains a defined operation Operation or function Function. Operation includes DPV(pv), UPV(pv), etc., and function Function includes MMF(pv), MFF(pv), etc. Indicates that statement n in program Prog defines the pointer variable pv.

[0045] 12) Alias ​​relationship: For a certain executable path in a program, if the path has a pointer variable pv and a pointer variable pv', and pv' and pv point to the same memory address, then the pointer variables pv' and the pointer variables pv are said to have an alias relationship, abbreviated as IsAlias(pv,pv').

[0046] 13) Abstract Syntax Tree (AST): A data structure that represents program statements in the form of a tree.

[0047] In order to better understand the embodiments of the present application, the memory vulnerability detection method in the related art and its existing shortcomings are explained.

[0048] Existing memory vulnerability detection methods mainly include the following two implementation methods:

[0049] The first implementation method is conceptual feature analysis. Conceptual feature analysis mainly refers to summarizing the conceptual features of vulnerabilities from one or more perspectives. This method believes that the characteristics of vulnerabilities include the objects affected by the vulnerabilities, the impact of the vulnerabilities, the methods and means of causing the impact, and the input types that cause the impact. The objects affected by the vulnerabilities mainly include user files, stack data, system directories, system programs, and system devices; the impacts of the vulnerabilities mainly include replacement, change, readability, appendability, creation, and lockability; the methods and means of causing the impact mainly include configuration errors, changing environment variables, improper execution of system protection mechanisms, and inheritance of non-essential permissions; the input types that cause the impact mainly include temporary files, environment variables, user commands, configuration files, and system call parameters. The conceptual feature analysis method is conducive to understanding vulnerability characteristics from a holistic and macro perspective, and has very important guiding significance for vulnerability research.

[0050] The second implementation method is formal feature analysis. Formal feature analysis is mainly based on the conceptual characteristics of the vulnerability, defines a formal description method, and describes the vulnerability characteristics more accurately. There are two classic studies on formal feature analysis:

[0051] (1) Formal feature analysis based on code attribute graph. Formal feature analysis based on code attribute graph first integrates the abstract syntax tree, control flow graph and data flow graph to propose a code attribute graph. Based on the code attribute graph, the vulnerability feature is abstracted into a triple (Ssrc, Sdst, Ss san), where Ssrc is the grammatical description of the source information controlled by the attacker, Sdst is the security sensitive operation description, and Ss san is the purification operation description. If there is no defined Ss san from the source Ssrc to the sensitive operation Sdst, the program will have a vulnerability.

[0052] (2) Formal feature analysis based on feature operations. Formal feature analysis based on feature operations mainly uses the feature operations involved in the vulnerability formation process as the entry point for research. It is a formal feature analysis method that many vulnerability researchers currently consider.

[0053] The above two methods mainly have the following shortcomings:

[0054] First, software vulnerability feature analysis research shows that existing conceptual feature analysis is often conducive to understanding and studying vulnerability features from a holistic and macro perspective, but it is difficult to apply vulnerability features to specific vulnerability discovery and detection.

[0055] Second, there are two problems with the existing formal feature analysis of vulnerabilities: on the one hand, many formal feature analysis methods can only analyze the features of a certain type or category of vulnerabilities, and the methods are not very scalable, which leads to the need to define different formal description methods for the features of different vulnerabilities. The lack of a unified standard is not conducive to the specific application of the methods; on the other hand, the formal feature analysis has a high degree of abstraction, but the resulting traversal rules are very complex, which is not conducive to the understanding and application of the rules.

[0056] In response to the above problems, an embodiment of the present application provides a memory vulnerability detection method, which is applied to a memory vulnerability detection device. The memory vulnerability detection device can be a terminal device with computing and communication capabilities, such as a desktop computer, a laptop computer, a tablet computer, etc. Figure 1 Schematic diagram of the implementation process of the memory vulnerability detection method of the present application embodiment. Figure 1 As shown, the method includes:

[0057] Step S101 , performing syntax analysis on the acquired source program to be detected to generate an abstract syntax tree.

[0058] A source program, also known as source code, is an uncompiled text file written in a certain programming language specification. It is a series of human-readable computer language instructions. Since the machine can only execute binary instructions, when executing the source program, it is necessary to use a compiler to compile the source program to obtain binary instructions. The abstract syntax tree is an abstract representation of the syntax structure of the source program. The syntax structure of the programming language is represented in a tree form, and each node on the tree represents a structure in the source code.

[0059] When implementing step S101, the front end of the GCC compiler may be used to perform syntax analysis on the source program and generate an abstract syntax tree file in .tu format.

[0060] Step S102: extracting feature information of each node in the abstract syntax tree.

[0061] As for user-defined variables and user-defined functions, we do not need to pay attention to the specific variable or function names, but only need to pay attention to the role of the variables or functions in the code. Therefore, after generating an abstract syntax tree based on the source program, we can first symbolize the node identifiers (that is, the node names) of each node in the abstract syntax tree to obtain symbolic node identifiers, and then extract feature information based on the symbolic node identifiers.

[0062] When implementing step S102, appropriate keywords may be selected from a defined keyword table according to the node identifier of each node and the operation implemented by each node, and the characteristic information of each node may be expressed in the form of "keyword_variable" or "keyword_function". For example, the node identifier of a certain node is pointer1_decl. It can be seen from the node identifier that the node is a definition declaration node of a pointer variable, and the keyword corresponding to the variable definition declaration is DECL, so the characteristic information of the node can be obtained as DECL_pointer1.

[0063] Step S103: determine the target node based on the characteristic information of each node.

[0064] Here, the target node at least includes a pointer definition node. The operation implemented by each node can be determined through the characteristic information of each node, so the pointer definition node can be determined and the pointer definition node is determined as the target node.

[0065] Step S104: Generate a pointer-related control flow graph based on the target node.

[0066] Here, when implementing step S104, the target node can be determined as the initial node, and then the child nodes of the initial node are traversed through the abstract syntax tree. If the child nodes of the initial node are pointer access nodes, memory allocation nodes or memory release nodes, the child nodes are added to the pointer-related control flow graph.

[0067] It should be noted that, in the embodiment of the present application, the child nodes of the initial node refer to the direct child nodes and indirect child nodes of the initial node.

[0068] Step S105, based on the pointer-related control flow graph and preset vulnerability detection rules, determine the vulnerability nodes in the source program to be detected.

[0069] Here, when implementing step S105, each executable path in the pointer-related control flow graph can be first obtained, and then each node in the executable path can be determined to satisfy the preset vulnerability detection rules, wherein the node satisfying the vulnerability detection rules is determined as a vulnerability node. In an embodiment of the present application, the vulnerability detection rules may include a missing release memory constraint, a repeated allocation memory constraint, and an allocation release mismatch constraint. When a node satisfies at least one of these three constraints, the node is considered to satisfy the vulnerability detection rules.

[0070] In the memory vulnerability detection method provided in the embodiment of the present application, the acquired source program to be detected is firstly subjected to grammatical analysis to generate an abstract syntax tree; then, feature information of each node in the abstract syntax tree is extracted; based on the feature information of each node, a target node is determined, wherein the target node includes at least a pointer definition node; a pointer-related control flow graph is generated based on the target node; based on the pointer-related control flow graph and preset vulnerability detection rules, a vulnerability node with a memory leak in the source program to be detected is determined, thereby formally describing the features of the memory vulnerability based on PCFG, and abstracting the vulnerability judgment rules based on the formal description of the relevant vulnerability features, which can effectively improve the efficiency of memory-related vulnerability detection.

[0071] In some embodiments, Figure 1 The step S101 "performing syntax analysis on the acquired source program to be detected to generate an abstract syntax tree" can be implemented by the following steps:

[0072] Step S1011, marking each variable in the source program to be detected to obtain a marked source program to be detected.

[0073] Here, since PCFG only contains pointer definition, pointer access, memory allocation and release, and related nodes to ensure the complete structure of the program, it is necessary to distinguish between pointer type variables and ordinary variables. Further, pointer type variables are marked as first type variables, and non-pointer type variables are marked as second type variables. For example, pointer variables are marked as pointer_decl, and ordinary variables are marked as var_decl.

[0074] Step S1012: using a compiler to perform semantic analysis on the marked source program to be detected, and generating an abstract syntax tree.

[0075] The abstract syntax tree generated through the above steps S1011 to S1012 has distinguished between pointer type variables and common type variables. Therefore, when subsequently generating pointer-related control flow graphs, targeted extraction and generation can be performed according to variable types, which can improve generation efficiency.

[0076] In some embodiments, the above step S102 "extracting feature information of each node in the abstract syntax tree" can be implemented by the following steps:

[0077] Step S1021: symbolize the node identifier of each node in the abstract syntax tree to obtain a symbolized node identifier.

[0078] Here, in the actual implementation process, the above step S1021 can be implemented through the following steps S211 to S213:

[0079] Step S211, obtaining the node identifier of each node in the abstract syntax tree.

[0080] Here, the node identifier of each node in the abstract syntax tree generated by the source program can only reflect the operation implemented by the node. For example, a line of code in the source program is: int test(int x), which is a function definition statement. In the abstract syntax tree, the node identifier corresponding to this line of code is function_decl; another line of code is char*data, which is a pointer variable definition statement. In the abstract syntax tree, the node identifier corresponding to this line of code is pointer_decl.

[0081] Step S212: when the node identifier is a user-defined variable name, the node identifier is mapped to a preset symbolic variable name.

[0082] Here, in the embodiment of the present application, the symbolic variable name can be pre-set, and further, the custom non-pointer variable name can be mapped to the symbolic non-pointer variable name, for example, the symbolic non-pointer variable name can be set to var1, var2, var3, ... and so on. The custom pointer variable name can be mapped to the symbolic pointer variable name, for example, the symbolic pointer variable name can be set to pointer1, pointer2, pointer3, ... and so on.

[0083] Continuing with the above example, in this step, the node identifier pointer_decl is mapped to pointer1_decl.

[0084] Step S213: when the node identifier is a user-defined function name, the node identifier is mapped to a preset symbolic function name.

[0085] Here, the preset symbolic function names may be fun1, fun2, fun3, ... and so on. Continuing with the above example, in this step, the node identifier function_decl is mapped to fun1_decl.

[0086] Step S1022: determining the characteristic keywords corresponding to each node in the abstract syntax tree.

[0087] In an embodiment of the present application, the correspondence between the node identifier and the feature keyword can be determined according to the operation actually implemented by the code. For example, if the operation implemented by the code is a variable declaration operation, then the corresponding feature keyword is DECL; if the operation actually implemented by the code is a memory allocation operation, then the corresponding feature keyword is MALLOC; if the operation actually implemented by the code is a conditional judgment operation, then the corresponding feature keyword is COND.

[0088] Step S1023, determining feature information of each node based on the symbolic node identifier and feature keyword of each node.

[0089] Here, when implementing step S1023, the characteristic information of each node is represented in the form of "keyword_symbolic node identifier". For example, the symbolic node identifier of fun1_decl is fun1, and the corresponding characteristic keyword is DECL. At this time, the characteristic information of the node is DECL_funl.

[0090] In some embodiments, step S104 "generating a pointer-related control flow graph based on the target node" can be performed as follows: Figure 2 The implementation of steps S1041 to S1043 is described below in conjunction with each step.

[0091] Step S1041, determining each target node as an initial node of the pointer-related control flow graph.

[0092] Here, since pointer access, memory allocation or memory release all require the definition of a pointer first, in an embodiment of the present application, the pointer definition node (ie, the target node) is used as the initial node.

[0093] Step S1042: determining a target child node of each initial node based on the abstract syntax tree and feature information of each node in the abstract syntax tree.

[0094] Here, the target child node is a node in the child node of the initial node that performs pointer access, memory allocation, memory release or guarantees the program completion structure, that is, the target child node includes a pointer access node, a memory allocation node, a memory release node and a node that guarantees the program completion structure.

[0095] Step S1043, adding the target child node to the pointer-related control flow graph.

[0096] Here, after traversing all the child nodes of the initial node in the abstract syntax tree, the final pointer-related control flow graph is obtained.

[0097] In some embodiments, the preset vulnerability detection rule includes at least one of an omitted memory release constraint, a repeated memory allocation constraint, and an allocation-release mismatch constraint. Correspondingly, step S105 "determining the vulnerability node in the source program to be detected based on the pointer-related control flow graph and the preset vulnerability detection rule" can be implemented by the following steps:

[0098] Step S1051, determining each executable path in the pointer-related control flow graph.

[0099] Here, in the pointer-related control flow graph, for a statement sequence formed by m nodes, if there is an edge between any two of the m nodes, then the m nodes are considered to form an executable path. In step S1051, each executable path in the pointer-related control flow graph is determined in sequence.

[0100] Step S1052, obtaining feature information of each to-be-detected node in each executable path.

[0101] Step S1053: Based on the feature information of each detection node, determine whether each detection node in the executable path satisfies the vulnerability detection rule.

[0102] Here, when a vulnerability detection rule of a detection node is determined, that is, it satisfies at least one of the missing release memory constraint, the repeated memory allocation constraint and the allocation and release mismatch constraint, the detection node is considered to meet the preset vulnerability detection rule, and step S1054 is entered at this time; when a vulnerability detection rule of a detection node is determined, that is, it does not meet any one of the missing release memory constraint, the repeated memory allocation constraint and the allocation and release mismatch constraint, it is determined that the detection node does not meet the vulnerability detection rule; at this time, the next node is detected until all detection nodes in the pointer-related control flow graph are traversed.

[0103] In an embodiment of the present application, the omitted release memory constraint, the repeated memory allocation constraint and the allocation-release mismatch constraint respectively include a basic constraint and an additional constraint. The basic constraints and additional constraints of the omitted release memory constraint, the repeated memory allocation constraint and the allocation-release mismatch constraint are described below.

[0104] The basic constraint of the missing release memory constraint is that there is a pointer definition node ni in the executable path, there is a memory allocation node nj in the successor node of node ni, and the data of node nj depends on the pointer variable pv defined by the pointer definition node ni. The additional constraint of the missing release memory constraint is that there is no first node nk or second node nu in the successor node of nj, wherein the first node nk is a memory allocation node, and the data of the first node nk depends on the pointer variable pv defined by the pointer definition node ni; the second node nu defines the pointer variable pv', the variable pv' defined by the second node nu is an alias relationship with the pointer variable pv defined by the pointer definition node ni, and the second node nu has a successor node nv (nv is also the successor node of nj), the node nv is a memory allocation node, and the data of the node nv depends on the pointer variable pv' defined by the node nu.

[0105] The basic constraint of the repeated memory allocation constraint is that there is a pointer definition node ni in the executable path, there is a memory allocation node nj in the successor node of node ni, and the data of memory allocation node nj depends on the pointer variable pv defined by pointer definition node ni. The additional constraint of the repeated memory allocation constraint is that there is a first node nk in the successor node of memory allocation node nj, wherein the first node nk is a memory allocation node, and the data of the first node nk depends on the pointer variable pv defined by pointer definition node ni; or the additional constraint of the repeated memory allocation constraint is that there is a node nu in the executable path, wherein node nu defines a pointer variable pv', and the pointer variable pv' is an alias relationship with the pointer variable pv, and node nu has a successor node nv (nv is also the successor node of nj), node nv performs a memory allocation operation, and the data of node nv depends on the pointer variable pv'.

[0106] The basic constraint of the allocation-release mismatch constraint is that there is a pointer definition node ni in the executable path, there is a memory allocation node nj in the successor node of node ni, and the data of node nj depends on the pointer variable pv defined by the pointer definition node ni. The additional constraint of the allocation-release mismatch constraint is that there is a node nk in the successor node of node nj: node nk performs a memory release operation and the release function does not match the allocation function, and the data of node nk depends on the pointer variable pv; or the additional constraint of the allocation-release mismatch constraint is that there is a node nu in the executable path, node nu defines a pointer variable pv', the pointer variable pv' is an alias relationship with the pointer variable pv, and node nu has a successor node nv (nv is also the successor node of nj), node nv performs a memory release operation and the release function does not match the allocation function, and the data of node nv depends on the pointer variable pv'.

[0107] Step S1054: determine the node to be detected as a vulnerable node with a memory leak.

[0108] Here, since memory leaks can be caused by missing memory release, repeated memory allocation, or mismatched allocation and release, when the node to be detected meets at least one of the constraints of missing memory release, repeated memory allocation, and mismatched allocation and release, the node to be detected is determined as a memory leak node. This ensures that all nodes that may have memory leaks are detected, ensuring the comprehensiveness and correctness of the detection.

[0109] In some embodiments, Figure 3 As shown, after step S105, the method further includes:

[0110] Step S106, determining the location information of the vulnerability node in the source program to be detected.

[0111] Here, after the vulnerability node is determined, the location information of the vulnerability node in the source program to be detected can be determined according to the identifier of the vulnerability node. In the embodiment of the present application, the location information can be represented by a line number.

[0112] In some embodiments, the code statement corresponding to the vulnerable node may also be determined.

[0113] Step S107, outputting the vulnerable node and the location information.

[0114] Here, when step S107 is implemented, the vulnerability node and location information may be output in a highlighted color on the display interface of the memory vulnerability detection device, for example, the vulnerability node and location information may be output in yellow, red, etc. In some embodiments, a preset vulnerability identifier may be output at the location where the vulnerability node is located in the source program, or a voice prompt may be output while outputting the vulnerability node and location information, etc., to prompt the user that a memory vulnerability is detected, so that the user can pay attention to and repair the detected memory vulnerability in a timely manner.

[0115] The following is an explanation of an exemplary application of an embodiment of the present application in a practical application scenario.

[0116] An embodiment of the present application provides a memory-related vulnerability detection method based on feature analysis. By analyzing a code segment containing memory-related vulnerabilities, the lexical, grammatical and semantic features involved in the memory vulnerabilities are obtained, and the features involved in the memory vulnerabilities are integrated into a pointer-related control flow graph. Then, based on the pointer-related control flow graph, three types of vulnerabilities, namely memory leakage, multiple release and reuse after release, are formally described in terms of features. Based on the formal description of relevant vulnerability features, vulnerability judgment rules are abstracted, which can effectively improve the efficiency of memory-related vulnerability detection.

[0117] Figure 4 A schematic diagram of an implementation framework of the memory vulnerability detection method provided in the embodiment of the present application, such as Figure 4 As shown, the framework of the memory vulnerability detection method based on feature analysis mainly includes: AST generation module 401, node feature extraction module 402, PCFG generation module 403 and vulnerability determination module 404. Each module is described below.

[0118] AST generation module 401: When implemented, this module uses the front end of the GNU Compiler Collection (GCC) to perform syntax analysis on the source code and generate an abstract syntax tree file in .tu format.

[0119] It should be noted that since PCFG only contains pointer definition, pointer access, memory allocation and release, and related nodes to ensure the complete structure of the program, pointer type variables and ordinary variables will be distinguished when using the GCC compiler to generate AST. The node name of the pointer variable in AST is pointer_decl, and the node name of the ordinary variable is var_decl. The efficiency of extracting the PCFG of the program directly from the text format AST is relatively low, so the AST needs to be further processed to store the abstract syntax tree in a designed data structure to facilitate traversal of the program AST. The data structure design of the node in the abstract syntax tree is shown in the following code segment:

[0120]

[0121] The data structure design of node attributes is shown in the following code snippet:

[0122]

[0123]

[0124] Node feature extraction module 402: mainly extracts feature information of program nodes from AST files. The basic idea of ​​node feature extraction is based on the symbolic processing of source code, so the program source code needs to be symbolic processed first. In the process of analyzing the source code, as far as user-defined variables and user-defined functions are concerned, the specific variable or function name is not concerned, but only the role of the variable or function in the code is concerned, so the source code can be symbolic processed.

[0125] The following steps are required to symbolize the source code:

[0126] Step 421, remove non-ASCII characters and comments in the code;

[0127] Step 422, mapping the user-defined variables one by one to the symbolic variable name set.

[0128] In actual implementation, the symbolic variable names can be var1, var2, and so on.

[0129] Step 423, mapping the user-defined functions one by one to the symbolic function name set.

[0130] In actual implementation, the symbolic function names can be fun1, fun2, and so on.

[0131] The following is an example of the code symbolization process. First, the source code of vulnerability instance 1 is shown in the following code segment:

[0132]

[0133]

[0134] In the above code segment, there is a user-defined function test() and two user-defined variables x and data. When performing code symbolization, first remove the non-ASCII characters and comments in the source code, that is, delete the " / * user-defined function test()* / " in the first line, and then map the user-defined variables and user-defined functions, that is, map the user-defined variables x and data in the source code to var1 and pointer1 respectively, and map the user-defined function test to fun1. At this time, the following symbolized code segment is obtained:

[0135]

[0136] Since the AST of the source code has been generated in advance based on the AST generation module, it is necessary to perform feature extraction on the nodes in the AST based on the idea of ​​code symbolization. Its essence is to extract the key information of the nodes and use the extracted results as the features of the PCFG nodes.

[0137] The implementation process of node feature extraction can be achieved through the following steps:

[0138] Step 31, mapping the user-defined variables one by one to the symbolic variable name set.

[0139] Here, symbolic variable names can be var1, var2, var3, etc.

[0140] Step 32, mapping the user-defined functions one by one to the symbolic function name set.

[0141] Here, the symbolic function names can be fun1, fun2, fun3, etc.

[0142] Step 33, based on the operation implemented by the current node, select a suitable keyword from the defined keyword table, and express the node feature in the form of "keyword_variable" or "keyword_function".

[0143] The following is an explanation of node feature extraction in conjunction with Table 1.

[0144] Table 1 Node feature extraction

[0145]

[0146] In Table 1, the first column "Source code statement" is the program source code statement, the second column "Source code symbolization processing" is the result of symbolization processing of the source code, the third column "AST node name" is the node name corresponding to the current source code statement in the AST, and the fourth column "Node feature extraction" is the key information obtained by processing the AST based on the source code symbolization process.

[0147] According to the results of the "node feature extraction" processing in the fourth column of Table 1, it can be seen that after the feature extraction of the AST node, the functions and variables involved in the source program are mapped to a unified symbol. For example, the feature extracted from char*data is DECL_pointer1. The feature only reflects that the statement declares a pointer variable named pointer1, ignoring the original specific name of the variable.

[0148] PCFG generation module 403: mainly used to generate PCFG corresponding to the program based on AST. The data structure adopted by PCFG is shown in the following code segment:

[0149]

[0150] In this code segment, id is used to uniquely identify the node of PCFG, lnum is used to record the line number of the node in the source program, nextid is used to indicate the next node id of the current node, isCond is used to indicate whether the current node is a conditional node. If so, leftid and rightid indicate the left branch id and right branch id of the current node respectively, otherwise leftid and rightid are both 0 by default. vector <string>nf is used to store the feature information of the current node, which is the node feature information extracted by the node feature extraction module.

[0151] In the embodiment of the present application, a recursive method is adopted to generate PCFG. In the process of generating PCFG, it is necessary to analyze the structures such as order, selection and loop in the program statement respectively. First, it is necessary to declare relevant variables and process the pointer variable declaration node of the program. Since PCFG only contains pointer definition, pointer access, memory allocation and release, and related nodes to ensure the complete structure of the program, in the process of generating PCFG, it is necessary to store all pointer variable declaration nodes in the program into a node set. Then determine whether the current node already exists in the node set. If so, it is necessary to add the current node to PCFG, otherwise abandon the current node, and analyze the next node of the current node. When all nodes are accessed, PCFG is output.

[0152] The vulnerability determination module 404 is mainly used to determine whether there is a vulnerability in the program based on the formal description of the vulnerability characteristics and the PCFG of the target program. The following determination rules are used in the determination process: For a certain executable path p∈Path in the program Prog, if there is a vulnerability-related dangerous point And if there is an element in the vulnerability-related danger point N that satisfies the vulnerability-related constraint C, then there is a vulnerability in the program.

[0153] The main idea of ​​the vulnerability determination method based on vulnerability features is to traverse the PCFG, record the vulnerability-related dangerous points N on the executable path during the traversal process, and determine whether there are elements in the vulnerability-related dangerous points N corresponding to a certain executable path that satisfy the vulnerability-related constraint C based on determination 1. If so, it is determined that there is a corresponding vulnerability in the program, and all vulnerability-related dangerous point information that causes the vulnerability is output.

[0154] In the embodiments of the present application, the characteristics of three memory-related vulnerabilities, namely memory leak, multiple release and reuse after release, are mainly analyzed, and the definition of vulnerability characteristics is given. Here, memory leak is taken as an example.

[0155] Memory leak refers to the failure to release some allocated heap memory during program execution due to improper coding by programmers, which leads to continuous consumption of system memory, and eventually causes program execution to slow down or computer system to crash. According to the definition of vulnerability characteristics, the memory leak characteristic σ(ML) = {N, C}. The following is a formal description of the vulnerability-related danger point N and the vulnerability characteristic constraint C.

[0156] Vulnerability related danger point N = {NDPV, NMMF, NMFF}, where:

[0157] NDPV represents the set of definition nodes of all pointer variables in the source program Prog. In the embodiment of the present application, NDPV can be expressed by formula (1-1):

[0158]

[0159] NMMF represents the set of all memory allocation nodes in the source program Prog. In the embodiment of the present application, NMMF can be expressed by formula (1-2):

[0160]

[0161] NMFF represents the set of all memory release nodes in the source program Prog. In the embodiment of the present application, NMFF can be expressed by formula (1-3):

[0162]

[0163] Vulnerability related constraints C = C1||C2||C3. The constraints C1, C2 and C3 are described below.

[0164] 1. Omitted memory release: C1=BC1∧AC1, where BC1 is the basic constraint and AC1 is the additional constraint.

[0165] The basic constraint BC1 indicates that for a certain executable path path in the program Prog, there is a node ni, and the node ni defines a pointer variable pv. There is a node nj in the successor node of the node ni, and the node nj performs the MMF (pv) operation, and the node nj data depends on the pointer variable pv defined by the node ni. In the embodiment of the present application, BC1 can be expressed by formula (1-4):

[0166]

[0167] After satisfying the basic constraint BC1, the additional constraint AC1 needs to be satisfied. The additional constraint AC1 includes two possible situations: ① For the executable path path, among the successor nodes of the node nj, there is no such node nk: the node nk performs the MFF (pv) operation, and the node nk data depends on the pointer variable pv defined by the node ni; ② For the executable path path, among the successor nodes of the node nj, there is no such node nu: the node nu defines the pointer variable pv', the variable pv' defined by the node nu is an alias relationship with the pointer variable pv defined by the node ni, and the node nu has a successor node nv (nv is also the successor node of nj), the node nv performs the MFF (pv') operation, and the node nv data depends on the pointer variable pv' defined by the node nu. In the embodiment of the present application, AC1 can be expressed by formula (1-5):

[0168]

[0169] 2. Repeatedly allocate memory: C2=BC2∧AC2, where BC2 is the basic constraint and AC2 is the additional constraint.

[0170] The basic constraint BC2 indicates that for a certain executable path path in the program Prog, there is a node ni, and the node ni defines a pointer variable pv. There is a node nj in the successor node of the node ni, and the node nj performs the MMF (pv) operation, and the node nj data depends on the pointer variable pv defined by the node ni. In the embodiment of the present application, BC2 can be expressed by formula (1-6):

[0171]

[0172] After satisfying the basic constraint BC2, the additional constraint AC2 also needs to be satisfied. The additional constraint AC2 includes two possible situations: ① For the executable path path, among the successor nodes of the node nj, there is such a node nk: the node nk performs the MMF (pv) operation, and the node nk data depends on the pointer variable pv defined by the node ni; ② For the executable path path, there is such a node nu on the path path: the node nu defines the pointer variable pv', the pointer variable pv' defined by the node nu is an alias relationship with the pointer variable pv defined by the node ni, and the node nu has a successor node nv (nv is also the successor node of nj), the node nv performs the MMF (pv') operation, and the node nv data depends on the pointer variable pv' defined by the node nu. In the embodiment of the present application, AC2 can be expressed by formula (1-7):

[0173]

[0174] 3. Allocation and release mismatch: C3=BC3∧AC3, where BC3 is the basic constraint and AC3 is the additional constraint.

[0175] The basic constraint BC3 indicates that for a certain executable path path in the program Prog, there is a node ni, and the node ni defines a pointer variable pv. There is a node nj in the successor node of the node ni, and the node nj performs the MMF (pv) operation, and the node nj data depends on the pointer variable pv defined by the node ni. In the embodiment of the present application, BC3 can be expressed by formula (1-8):

[0176]

[0177] After satisfying the basic constraint BC3, the additional constraint AC3 needs to be satisfied. The additional constraint AC3 includes two possible situations: ① For the executable path path, among the successor nodes of node nj, there is a node nk: operation (i.e., the release function does not match the allocation function), and the data of node nk depends on the pointer variable pv defined by node ni; ② For the executable path path, there is such a node nu on the path path: node nu defines a pointer variable pv', the pointer variable pv' defined by node nu is an alias relationship with the pointer variable pv defined by node ni, and node nu has a successor node nv (nv is also the successor node of nj), and node nv performs operation (i.e., the release function does not match the allocation function), and the node nv data depends on the pointer variable pv' defined by the node nu. In the embodiment of the present application, AC3 can be expressed by formula (1-9):

[0178]

[0179] In the memory vulnerability detection method provided in the embodiment of the present application, by analyzing a large number of code segments containing memory-related vulnerabilities, the lexical, grammatical and semantic features involved in the generation of memory-related vulnerabilities are summarized, and a vulnerability feature definition and a vulnerability feature formal description method are proposed. Due to the definition of vulnerability features proposed in the embodiment of the present application, the common features of memory-related vulnerabilities can be reflected, which is conducive to the study of the commonality of vulnerability generation. At the same time, the features of memory-related vulnerabilities are integrated into the control flow graph, a pointer-related control flow graph is proposed, and the three vulnerabilities of memory leakage, multiple release and reuse after release are formally described based on PCFG, and the vulnerability judgment rules are abstracted based on the formal description of the relevant vulnerability features. Since PCFG only contains pointer definition, pointer access, memory allocation and release, and related nodes that ensure the complete structure of the program, and each node in the graph has a characteristic attribute, the memory-related vulnerability detection method proposed based on the formal description of the relevant vulnerability features and PCFG can effectively improve the detection efficiency of memory-related vulnerabilities.

[0180] The present application provides a memory vulnerability detection device. Figure 5 Schematic diagram of the composition structure of the memory vulnerability detection device according to the embodiment of the present application. Figure 5 As shown, the memory vulnerability detection device 500 includes: a syntax analysis module 501, a feature extraction module 502, a first determination module 503, a first generation module 504 and a second determination module 505, wherein:

[0181] The syntax analysis module 501 is used to perform syntax analysis on the acquired source program to be detected and generate an abstract syntax tree;

[0182] The feature extraction module 502 is used to extract feature information of each node in the abstract syntax tree;

[0183] The first determination module 503 is used to determine a target node based on feature information of each node, wherein the target node at least includes a pointer definition node;

[0184] The first generating module 504 is used to generate a pointer-related control flow graph based on the target node;

[0185] The second determination module 505 is used to determine the vulnerability node with memory leak in the source program to be detected based on the pointer-related control flow graph and the preset vulnerability detection rules.

[0186] In some embodiments, the syntax analysis module 501 further includes:

[0187] A marking unit, used for marking each variable in the source program to be detected to obtain a marked source program to be detected, wherein pointer type variables are marked as first type variables, and non-pointer type variables are marked as second type variables;

[0188] The semantic analysis unit is used to use the compiler to perform semantic analysis on the marked source program to be detected and generate an abstract syntax tree.

[0189] In some embodiments, the feature extraction module 502 further includes:

[0190] A symbolic processing unit, used for symbolic processing of the node identifier of each node in the abstract syntax tree to obtain a symbolic node identifier;

[0191] A first determining unit, used to determine a characteristic keyword corresponding to each node in the abstract syntax tree;

[0192] The second determining unit is used to determine the characteristic information of each node based on the symbolic node identifier and characteristic keywords of each node.

[0193] In some embodiments, the symbolization processing unit includes:

[0194] A first acquisition subunit, used to acquire a node identifier of each node in the abstract syntax tree;

[0195] A first mapping subunit, configured to map the node identifier to a preset symbolic variable name when the node identifier is a user-defined variable name;

[0196] The second mapping subunit is used to map the node identifier to a preset symbolic function name when the node identifier is a user-defined function name.

[0197] In some embodiments, the first generating module 504 further includes:

[0198] A third determining unit, used to determine each target node as an initial node of the pointer-related control flow graph;

[0199] a fourth determining unit, configured to determine a target child node of each initial node based on the abstract syntax tree and feature information of each node in the abstract syntax tree, wherein the target child node is a pointer access node, a memory allocation node, or a memory release node;

[0200] The adding node unit is used to add the target child node to the pointer-related control flow graph.

[0201] In some embodiments, the preset vulnerability detection rule includes at least one of an omitted memory release constraint, a repeated memory allocation constraint, and an allocation-release mismatch constraint. Correspondingly, the second determination module 505 further includes:

[0202] A fifth determining unit, configured to determine each executable path in the pointer-related control flow graph;

[0203] An acquisition unit, used for acquiring each node to be detected in each executable path;

[0204] The sixth determination unit is used to determine the node to be detected as a vulnerable node with memory leak when the node to be detected meets at least one of the constraints of missed release memory, repeated allocation memory and allocation and release mismatch.

[0205] In some embodiments, the apparatus further comprises:

[0206] A third determination module is used to determine the location information of the vulnerability node in the source program to be detected;

[0207] An output module is used to output the vulnerability node and the location information.

[0208] It should be noted that the description of the above device embodiment is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of the present application, please refer to the description of the method embodiment of the present application for understanding.

[0209] It should be noted that in the embodiments of the present application, if the above-mentioned memory vulnerability detection method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk, and other media that can store program codes. In this way, the embodiments of the present application are not limited to any specific combination of hardware and software.

[0210] Correspondingly, an embodiment of the present application further provides a storage medium, on which a memory vulnerability detection program is stored. When the memory vulnerability detection program is executed by a processor, the steps of the memory vulnerability detection method provided in other embodiments are implemented.

[0211] Correspondingly, an embodiment of the present application provides a memory vulnerability detection device, Figure 6 Schematic diagram of the composition structure of the memory vulnerability detection device 600 according to the embodiment of the present application. Figure 6 As shown, the memory vulnerability detection device 600 at least includes: a memory 601, a communication bus 602 and a processor 603, wherein:

[0212] The memory 601 is used to store a memory vulnerability detection program;

[0213] The communication bus 602 is used to realize the connection and communication between the processor and the memory;

[0214] The processor 603 is used to execute the memory vulnerability detection program stored in the memory to implement the steps of the memory vulnerability detection method provided in other embodiments.

[0215] Memory 601 can be volatile memory or non-volatile memory, and can also include both volatile and non-volatile memory. Wherein, non-volatile memory can be read-only memory (ROM, Read Only Memory), programmable read-only memory (PROM, Programmable Read-Only Memory), erasable programmable read-only memory (EPROM, Erasable Programmable Read-Only Memory), flash memory (Flash Memory) etc. Volatile memory can be random access memory (RAM, Random Access Memory), which is used as external cache. By exemplary but not limiting explanation, many forms of RAM are available, such as static random access memory (SRAM, Static Random Access Memory), synchronous static random access memory (SSRAM, Synchronous Static Random Access Memory). The memory 601 described in the embodiment of the present application is intended to include these and any other suitable types of memory.

[0216] As an example of the method provided in the embodiment of the present application being implemented by a combination of software and hardware, the method provided in the embodiment of the present application can be directly embodied as a combination of software modules executed by the processor 603. The software module can be located in a storage medium, and the storage medium is located in the memory 601. The processor 603 reads the executable instructions included in the software module in the memory 601, and combines the necessary hardware (for example, including the processor 603 and other components connected to the communication bus 602) to implement the memory vulnerability detection method provided in the above embodiment.

[0217] As an example, the processor 603 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0218] The description of the above memory vulnerability detection device and storage medium embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the memory vulnerability detection device and storage medium embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

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

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

[0221] The above description is only a preferred embodiment of the present application and is not intended to limit the protection scope of the present application.< / string>

Claims

1. A memory vulnerability detection method, characterized in that: The method comprises: Perform syntax analysis on the acquired source program to be tested and generate an abstract syntax tree; Extracting feature information of each node in the abstract syntax tree; Determine a target node based on the characteristic information of each node, wherein the target node at least includes a pointer definition node; Generate a pointer-related control flow graph based on the target node, wherein when a child node of the target node is a pointer access node, a memory allocation node, or a memory release node, the pointer-related control flow graph includes the child node; Based on the pointer-related control flow graph and preset vulnerability detection rules, vulnerability nodes in the source program to be detected are determined.

2. The method according to claim 1, characterized in that The step of performing grammatical analysis on the acquired source program to be detected and generating an abstract syntax tree includes: Marking each variable in the source program to be detected to obtain a marked source program to be detected, wherein pointer type variables are marked as first type variables, and non-pointer type variables are marked as second type variables; The compiler is used to perform semantic analysis on the marked source program to be detected and generate an abstract syntax tree.

3. The method according to claim 2, characterized in that The extracting feature information of each node in the abstract syntax tree includes: Symbolize the node identifier of each node in the abstract syntax tree to obtain a symbolized node identifier; Determine the feature keywords corresponding to each node in the abstract syntax tree; Based on the symbolic node identifier and characteristic keywords of each node, characteristic information of each node is determined.

4. The method according to claim 3, characterized in that The symbolizing of the node identifiers of the nodes in the abstract syntax tree to obtain symbolized node identifiers includes: Obtaining a node identifier of each node in the abstract syntax tree; When the node identifier is a user-defined variable name, the node identifier is mapped to a preset symbolic variable name; When the node identifier is a user-defined function name, the node identifier is mapped to a preset symbolic function name.

5. The method according to claim 1, characterized in that The target node at least includes a pointer definition node. Correspondingly, generating a pointer-related control flow graph based on the target node includes: Determine each target node as an initial node of a pointer-related control flow graph; Based on the abstract syntax tree and feature information of each node in the abstract syntax tree, determining a target child node of each initial node, wherein the target child node includes a pointer access node, a memory allocation node or a memory release node, and a node capable of ensuring a complete structure of a program; The target child node is added to the pointer-related control flow graph.

6. The method according to claim 1, characterized in that The step of determining a vulnerability node having a memory leak in a source program to be detected based on the pointer-related control flow graph and a preset vulnerability detection rule includes: Determining each executable path in the pointer-related control flow graph; Get each node to be detected in each executable path; When the node to be detected meets the vulnerability detection rule, the node to be detected is determined as a vulnerable node.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: Determine the location information of the vulnerability node in the source program to be detected; The vulnerable node and the location information are output.

8. A memory vulnerability detection device, characterized in that: The device at least comprises: a syntax analysis module, a feature extraction module, a first determination module, a first generation module and a second determination module, wherein: The syntax analysis module is used to perform syntax analysis on the acquired source program to be detected and generate an abstract syntax tree; The feature extraction module is used to extract feature information of each node in the abstract syntax tree; The first determination module is used to determine a target node based on feature information of each node, wherein the target node at least includes a pointer definition node; The first generating module is used to generate a pointer-related control flow graph based on the target node, wherein when a child node of the target node is a pointer access node, a memory allocation node or a memory release node, the pointer-related control flow graph includes the child node; The second determination module is used to determine the vulnerability node in the source program to be detected based on the pointer-related control flow graph and preset vulnerability detection rules.

9. A memory vulnerability detection device, characterized in that: The memory vulnerability detection device comprises at least: a memory, a communication bus and a processor, wherein: The memory is used to store a memory vulnerability detection program; The communication bus is used to realize the connection and communication between the processor and the memory; The processor is used to execute the memory vulnerability detection program stored in the memory to implement the steps of the memory vulnerability detection method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a memory vulnerability detection program, and when the memory vulnerability detection program is executed by the processor, the steps of the memory vulnerability detection method described in any one of claims 1 to 7 are implemented.

Images