Program vulnerability detection method, device, electronic device and medium

Abstract

The present disclosure provides a method, device, electronic device and medium for detecting program vulnerabilities, which relate to the fields of network security or financial technology. The method for detecting program vulnerabilities includes: obtaining program source code, extracting intermediate codes in the program source code, and generating a control flow graph according to the intermediate codes; traversing each node in the control flow graph according to a pre-created vulnerability pattern library, and collecting vulnerability path constraints corresponding to preset target defects; after performing SMT standardized conversion on the vulnerability path constraints, solving the vulnerability path constraints using an SMT solver to determine whether the vulnerability path is reachable; if so, detecting whether there is a security vulnerability in the reachable path in the vulnerability path; otherwise, filtering the unreachable path in the vulnerability path.

Description

Technical Field

[0001] The present disclosure relates to the field of network security or financial technology, and in particular to a program vulnerability detection method, device, electronic device and medium. Background Art

[0002] Program vulnerabilities are one of the main sources of information security risks and an important target in network attack and defense. The detection and mining of program vulnerabilities, or software vulnerabilities, has always been a research hotspot in academia and the financial field. There are two main detection methods: one is static detection and mining of vulnerabilities based on software source code; the other is source code vulnerability detection based on deep learning.

[0003] Among them, the static vulnerability detection method based on software source code constructs a behavior set of software control flow through static analysis technology, obtains the real-time verification value of each judgment block during the software execution process, and performs real-time comparison and verification with the software control flow behavior feature set to output the software vulnerability detection result. However, this static vulnerability detection method is based on the anomalies of the program's own control flow, and cannot detect defects that do not change the program's control flow. For example, if an external attack only affects the value of the program variable (changes in key variables such as the amount), it cannot be detected; in addition, this static vulnerability detection method is actually a dynamic detection solution, and the verification during the execution process will inevitably affect the program performance.

[0004] The source code vulnerability detection method based on deep learning can automatically complete the feature extraction of source code, build a vulnerability detection model to detect vulnerabilities in the program. However, this source code vulnerability detection method lacks a preprocessing process. The abstract syntax tree, control flow graph and program dependency graph are the most important structural elements of the program. Their semantic dimensions are extensive and complex, and they need to rely on the interpretation ability of the classifier. On the other hand, it is difficult to obtain samples. Under the premise that the feature vector is a high-dimensional vector composed of splicing, it is a high-cost and difficult task to obtain a sufficient number of reasonably distributed vulnerability programs and label them. In addition, there is a defect of insufficient interpretability. Summary of the invention

[0005] In view of the above-mentioned deficiencies in the prior art, the present disclosure provides a program vulnerability detection method, device, electronic device and medium to solve the problem that the current program vulnerability detection cannot detect defects that do not change the program control flow and the problem that the program performance is affected in the verification of the dynamic detection execution process.

[0006] One aspect of the present disclosure provides a program vulnerability detection method, including: obtaining program source code, extracting intermediate code in the program source code, and generating a control flow graph according to the intermediate code; traversing each node in the control flow graph according to a pre-created vulnerability pattern library, and collecting vulnerability path constraints corresponding to preset target defects; after performing SMT standardized conversion on the vulnerability path constraints, solving the vulnerability path constraints using an SMT solver to determine whether the vulnerability path is reachable; if so, detecting whether there is a security vulnerability in the reachable path in the vulnerability path; otherwise, filtering the unreachable path in the vulnerability path.

[0007] According to an embodiment of the present disclosure, program source code is obtained and intermediate code in the program source code is extracted, including: the program source code is Java bytecode, and the intermediate code in the program source code is extracted using a Soot framework, and the extracted intermediate code includes at least one of Baf, Jimple, Shimple or Grimp format intermediate codes.

[0008] According to an embodiment of the present disclosure, the intermediate code is a Jimple format intermediate code, and the Jimple format intermediate code in the program source code is extracted using the Soot framework. The method includes: declaring all variables in the program source code at the beginning of Jimple; converting constant data in the program source code into byte data; prefixing all method calls in the program source code with virtualinvoke or staticinvoke; and expressing all control flows in the program source code with goto label jump statements.

[0009] According to an embodiment of the present disclosure, a control flow graph is generated according to an intermediate code, including: initializing an empty vertex set V and an empty edge set E; traversing each statement in the Jimple format intermediate code, creating a new vertex for each statement, and adding the new vertex to the empty vertex set V; traversing each statement in the Jimple format intermediate code, determining whether each statement is a goto label jump statement, and if so, adding a first new edge in the empty edge set E, whose outgoing vertex is a new vertex of the goto label jump statement and whose incoming vertex is a new vertex corresponding to the label; otherwise, adding a second new edge in the empty edge set E, whose outgoing vertex is a new vertex of the current statement and whose incoming vertex is a new vertex of the next statement of the current statement.

[0010] According to an embodiment of the present disclosure, the vulnerability pattern library includes at least one of the following vulnerability patterns: Jsp Trojan, Sql injection, Servlet thread insecurity or server-side request forgery.

[0011] According to an embodiment of the present disclosure, each node in the control flow graph is traversed according to a pre-created vulnerability pattern library, including: using a depth-first traversal algorithm to perform node traversal, with the starting point of the traversal path being the start node, the end point of the traversal path being a node that matches any vulnerability pattern in the vulnerability pattern library, and synchronously recording all assignment statements and jump conditions on the traversal path.

[0012] According to an embodiment of the present disclosure, the vulnerability path constraint is converted to SMT standard, including: using an infix conditional to prefix conditional algorithm or a prefix expression bracket generation algorithm to convert the vulnerability path constraint to SMI-LIBstandard form.

[0013] According to an embodiment of the present disclosure, the SMT solver is theorem solver Z3. After the step of performing SMT standard conversion on the vulnerability path constraint, it also includes: adding the SMI-LIB standard tail to the vulnerability path constraint after the SMT standard conversion to obtain a legal constraint set of the vulnerability path.

[0014] Another aspect of the present disclosure provides a program vulnerability detection device, including: a feature extraction module, used to obtain program source code, extract intermediate codes in the program source code, and generate a control flow graph according to the intermediate codes; a node traversal module, used to traverse each node in the control flow graph according to a pre-created vulnerability pattern library, and collect vulnerability path constraints corresponding to preset target defects; an SMT solving module, used to perform SMT standardized conversion on the vulnerability path constraints, and then use the SMT solver to solve the vulnerability path constraints to determine whether the vulnerability path is reachable; and a vulnerability detection module, used to detect whether there is a security vulnerability in the accessible path in the vulnerability path when the vulnerability path is reachable; otherwise, filter the inaccessible path in the vulnerability path.

[0015] According to an embodiment of the present disclosure, the feature extraction module also includes: an intermediate code extraction unit, which is used to extract the intermediate code in the program source code using the Soot framework, and the intermediate code is the Jimple format intermediate code; a control flow graph generation unit, which is used to initialize an empty vertex set V and an empty edge set E; traverse each statement in the Jimple format intermediate code, create a new vertex for each statement, and add the new vertex to the empty vertex set V; traverse each statement in the Jimple format intermediate code, and determine whether each statement is a goto label jump statement. If so, add a first new edge in the empty edge set E, whose outgoing vertex is the new vertex of the goto label jump statement and whose incoming vertex is the new vertex corresponding to the label; otherwise, add a second new edge in the empty edge set E, whose outgoing vertex is the new vertex of the current statement and whose incoming vertex is the new vertex of the next statement of the current statement.

[0016] According to an embodiment of the present disclosure, the node traversal module also includes: a pattern matching unit, which is used to perform node traversal using a depth-first traversal algorithm, where the starting point of the traversal path is the start node, and the end point of the traversal path is a node that matches any vulnerability pattern in the vulnerability pattern library; a synchronization recording unit, which is used to synchronously record all assignment statements and jump conditions on the traversal path.

[0017] According to an embodiment of the present disclosure, the SMT solving module also includes: a path constraint conversion unit, which is used to convert the vulnerability path constraint into the SMI-LIB standard form by adopting an infix conditional to prefix conditional algorithm or a prefix expression bracket generation algorithm; a standard tail adding unit, which is used to add the SMI-LIB standard standard tail to the vulnerability path constraint in the SMI-LIB standard form to obtain a legal constraint set of the vulnerability path.

[0018] Another aspect of the present disclosure provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors execute the method as described above.

[0019] Another aspect of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the above method when executed.

[0020] Another aspect of the present disclosure provides a computer program, which includes computer executable instructions, and the instructions are used to implement the method described above when executed.

[0021] Compared with the prior art, the program vulnerability detection method, device, electronic device and medium provided by the present disclosure have at least the following beneficial effects:

[0022] (1) The present disclosure provides a new method for generating IR flow chart based on Jimple IR, which provides a reliable basis for subsequent vulnerability path search and can lock the vulnerability scope at the line level;

[0023] (2) The present disclosure automatically converts the path constraints in IR form into constraint sets that conform to the syntax of the Microsoft z3 SMI-LIB standard, thereby solving the constraints on the vulnerability path, achieving path-sensitive defect detection, and reducing misidentification;

[0024] (3) The present disclosure can realize program vulnerability detection, specifically interpretable static vulnerability detection at the program flow, function, and method levels;

[0025] (4) The present disclosure improves the detection efficiency, high detection completeness and high detection precision of program vulnerability detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The above and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0027] Figure 1 The exemplary system architecture of the program vulnerability detection method and device according to the embodiment of the present disclosure is schematically shown;

[0028] Figure 2 A flowchart of a program vulnerability detection method according to an embodiment of the present disclosure is schematically shown;

[0029] Figure 3 The following schematically shows an operation flow chart of a program vulnerability detection method according to an embodiment of the present disclosure;

[0030] Figure 4 The following schematically shows an operation flow chart of extracting Jimple format intermediate code using Soot framework according to an embodiment of the present disclosure;

[0031] Figure 5 The schematic diagram shows the operation process of generating a control flow graph according to the Jimple format intermediate code according to an embodiment of the present disclosure;

[0032] Figure 6 The structure of a control flow graph generated according to an embodiment of the present disclosure is schematically shown;

[0033] Figure 7 The schematic diagram shows a structural form of a vulnerability path constraint generated according to an embodiment of the present disclosure;

[0034] Figure 8 The structure of the algorithm for converting an infix conditional expression to a prefix conditional expression according to an embodiment of the present disclosure is schematically shown;

[0035] Fig. 9 The structure of the prefix expression bracket generation algorithm according to the embodiment of the present disclosure is schematically shown;

[0036] Fig.10 A block diagram of a program vulnerability detection device according to an embodiment of the present invention is schematically shown;

[0037] Fig.11A A block diagram of a feature extraction module according to an embodiment of the present invention is schematically shown;

[0038] Fig. 11B Schematically shows a block diagram of a path constraint collection module according to an embodiment of the present invention;

[0039] Fig. 11C A block diagram schematically shows a path constraint solving module according to an embodiment of the present invention; and

[0040] Fig.12 A block diagram of an electronic device according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0041] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0042] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0043] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.

[0044] In the case of using expressions such as "at least one of A, B, and C, etc.", it should generally be interpreted in accordance with the meaning of the expression generally understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.). In the case of using expressions such as "at least one of A, B, or C, etc.", it should generally be interpreted in accordance with the meaning of the expression generally understood by those skilled in the art (for example, "a system having at least one of A, B, or C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0045] Some block diagrams and / or flow charts are shown in the accompanying drawings. It should be understood that some boxes or combinations thereof in the block diagrams and / or flow charts 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, or other programmable data processing device, so that these instructions can create a device for implementing the functions / operations described in these block diagrams and / or flow charts when executed by the processor. The technology of the present disclosure can be implemented in the form of hardware and / or software (including firmware, microcode, etc.). In addition, the technology of the present disclosure can take the form of a computer program product on a computer-readable storage medium storing instructions, which can be used by an instruction execution system or used in conjunction with an instruction execution system.

[0046] Before describing the specific embodiments of the present disclosure in detail, technical terms are first explained to facilitate a better understanding of the present disclosure.

[0047] IR (Intermediate Representation): Intermediate expression, or intermediate code, specifically LLVM intermediate representation, is an intermediate language of LLVM. The LLVM project is a modular, reusable set of compilers and tool chains.

[0048] A control flow graph (CFG), also called a control flow diagram, is an abstract representation of a process or program. It is an abstract data structure used in compilers and maintained internally by the compiler. It represents all the paths that a program will traverse during execution. It uses a graph to represent the possible execution flows of all basic blocks within a process, and can also reflect the real-time execution of a process.

[0049] Soot framework: It is an open source Java bytecode optimization framework written in Java language developed by the Sable research group of McGill University. It can convert the class files generated by Java compilation into Soot's intermediate representation, providing users with an extensible analysis framework such as bytecode file analysis, optimization, decompilation, and annotation. Analysts can use Soot to perform Java code analysis.

[0050] SMT solver: The full name is Satisfiability Modulo Theories, which can be translated as "satisfiability modulo theory", "satisfiability problem under multiple theories" or "satisfiability problem under specific (background) theory". Its decision algorithm is called SMT solver. Simply put, an SMT formula is a logical formula combined with a theoretical background, in which the proposition variables can represent theoretical formulas.

[0051] Theorem Prover Z3: is an open source constraint SMT solver developed by Microsoft that can check the satisfiability of logical expressions. Theorem Prover Z3 provides a compelling match for software analysis and verification tools because several common software constructs map directly to the supported theory. The input format of theorem prover Z3 is an extension of the SMT-LIB2.0 standard. A Z3 script is a sequence of commands.

[0052] The embodiments of the present disclosure provide a method and device for detecting program vulnerabilities. The method includes: obtaining program source code, extracting intermediate codes in the program source code, and generating a control flow graph according to the intermediate codes; traversing each node in the control flow graph according to a pre-created vulnerability pattern library, and collecting vulnerability path constraints corresponding to preset target defects; after performing SMT standardized conversion on the vulnerability path constraints, solving the vulnerability path constraints using an SMT solver to determine whether the vulnerability path is reachable; if so, detecting whether there is a security vulnerability in the reachable path in the vulnerability path; otherwise, filtering the unreachable path in the vulnerability path.

[0053] Figure 1 The exemplary system architecture 100 of the method and apparatus for detecting application vulnerability according to the embodiment of the present disclosure is schematically shown. It should be noted that: Figure 1 What is shown is merely an example of a system architecture to which the embodiments of the present disclosure can be applied, in order to help those skilled in the art understand the technical content of the present disclosure, but it does not mean that the embodiments of the present disclosure cannot be used in other devices, systems, environments or scenarios.

[0054] like Figure 1 As shown, the system architecture 100 according to this embodiment may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired and / or wireless communication links, etc.

[0055] Users can use terminal devices 101 , 102 , 103 to interact with server 105 via network 104 to receive or send messages, etc.

[0056] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0057] The server 105 may be a server that provides various services, such as a background management server that provides support for websites browsed by users using the terminal devices 101 , 102 , and 103 (only an example).

[0058] It should be noted that the program vulnerability detection method provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the program vulnerability detection device provided in the embodiment of the present disclosure can generally be set in the server 105. The program vulnerability detection method provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Accordingly, the program vulnerability detection device provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105.

[0059] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to the implementation requirements.

[0060] Figure 2 The flowchart of the program vulnerability detection method according to the embodiment of the present disclosure is schematically shown.

[0061] like Figure 2 As shown, the program vulnerability detection method may include operations S201 to S203.

[0062] In operation S201, a program source code is obtained, an intermediate code in the program source code is extracted, and a control flow graph is generated according to the intermediate code.

[0063] In operation S202, each node in the control flow graph is traversed according to a pre-created vulnerability pattern library to collect vulnerability path constraints corresponding to preset target defects.

[0064] In operation S203, after the vulnerability path constraint is converted into an SMT standard, the vulnerability path constraint is solved using an SMT solver to determine whether the vulnerability path is reachable.

[0065] In operation S204, if yes, then detect whether the reachable paths in the vulnerability paths have security vulnerabilities; otherwise, filter out the unreachable paths in the vulnerability paths.

[0066] Through the embodiments of the present disclosure, the present disclosure establishes a vulnerability pattern library as a standard for vulnerability detection, combines the intermediate code IR extraction and control flow graph generation of the program source code to search for suspicious paths, and then combines path constraint collection and constraint solving to complete flow-sensitive and path-sensitive screening of suspicious paths, thereby achieving a program vulnerability detection effect with high completeness and high precision.

[0067] Figure 3 The operational flow chart of the program vulnerability detection method according to an embodiment of the present disclosure is schematically shown.

[0068] like Figure 3 As shown, in the embodiment of the present disclosure, the program source code is Java bytecode, and the Soot framework is used to extract the intermediate code in the program source code. The extracted intermediate code includes at least one of Baf, Jimple, Shimple or Grimp format intermediate codes.

[0069] For example, the present disclosure uses the Soot framework, which was developed by the Sable research team of McGill University and was originally designed to optimize Java bytecode, to extract intermediate code IR. For input Java bytecode, the Soot framework provides four different levels of intermediate code IR extraction: Baf, Jimple, Shimple, and Grimp.

[0070] Among them: Baf intermediate code is an instruction set based on stack operations, and its intermediate representation is the most concise; Jimple intermediate code is the core of the Soot framework and the most important of the four IRs. It is a typed, three-address and statement-based intermediate code; Shimple intermediate code is a static single assignment (SSA) Jimple representation version; Grimp intermediate code can construct a tree structure, which is closer to Java source code, suitable for disassembly and easy to read.

[0071] Since Jimple is the most commonly used in the Soot framework, the intermediate code extracted by the present disclosure can be, for example, Jimple format intermediate code. The expression of Jimple format intermediate code is a three-address code expression, and each instruction contains at most three variables; and Jimple only contains 15 instructions, which is more conducive to analysis than Java bytecode.

[0072] It can be understood that, in other embodiments, Baf, Shimple or Grimp format intermediate codes may also be used for IR extraction, and the specific IR extraction steps will not be repeated in this disclosure.

[0073] Figure 4 The flowchart schematically shows an operation of extracting Jimple format intermediate code by using Soot framework according to an embodiment of the present disclosure.

[0074] like Figure 4 As shown, using the Soot framework to extract the Jimple format intermediate code in the program source code may include sub-operations S401 to S404.

[0075] In operation S401, all variables in the program source code are declared at the beginning of Jimple.

[0076] In operation S402, constant data in the program source code is converted into byte data.

[0077] In operation S403, all method calls in the program source code are prefixed with virtualinvoke or staticinvoke.

[0078] Among them, the role of virtualinvoke is actually to call the object method in the instantiated object. It will search for methods according to the current actual object type, and search upwards in order according to the inheritance or implementation hierarchy until it finds a method closest to the current implementation class. Staticinvoke is actually a class-oriented instruction. For a class loaded into the jvm, according to the class file loading process, during the execution process, the relevant statically modified class variables, static methods, or static code blocks in the class will actually be loaded. It can be seen that virtualinvoke or staticinvoke are actually different instructions for object methods and class methods.

[0079] In operation S404, the control flows in the program source code are all expressed with goto label jump statements.

[0080] It should be noted that there is no obvious order in which the above sub-operations S401 to S404 are performed. Figure 4 Only one optional intermediate code extraction processing sequence is listed. In other embodiments, the sub-operations S401 to S404 may be changed in sequence according to actual needs of the user, and the present disclosure does not limit this.

[0081] Through the above sub-operations S401 to S404, the embodiment of the present disclosure can greatly facilitate the subsequent Java file data flow and control flow analysis.

[0082] Figure 5 The operation process of generating a control flow graph according to the Jimple format intermediate code according to an embodiment of the present disclosure is schematically shown.

[0083] like Figure 5 As shown, in the embodiment of the present disclosure, generating a control flow graph according to the Jimple format intermediate code may include sub-operations S501 to S503.

[0084] In operation S501, an empty vertex set V and an empty edge set E are initialized;

[0085] In operation S502, each statement in the Jimple format intermediate code is traversed, a new vertex is created for each statement, and the new vertex is added to the empty vertex set V;

[0086] In operation S503, each statement in the Jimple format intermediate code is traversed to determine whether each statement is a gotolabel jump statement. If so, a first new edge is added to the empty edge set E, whose outgoing vertex is a new vertex of the goto label jump statement and whose incoming vertex is the new vertex corresponding to label; otherwise, a second new edge is added to the empty edge set E, whose outgoing vertex is a new vertex of the current statement and whose incoming vertex is a new vertex of the next statement of the current statement.

[0087] Since the goto label jump statement corresponds to any control flow in the program source file, the embodiment of the present disclosure can perform flow-sensitive screening of suspected vulnerability paths.

[0088] Figure 6 The structure of a control flow graph generated according to an embodiment of the present disclosure is schematically shown.

[0089] like Figure 6 As shown, the {ifi3≤i2 goto label10} statement in the lower right corner is the goto label jump statement. At this time, the goto label jump statement serves as the outgoing vertex added to the empty edge set E, and {label10:return ""} is the label corresponding statement. The label corresponding statement serves as the incoming vertex added to the empty edge set E that matches the aforementioned outgoing vertex. The first new edge is determined based on the mutually matching outgoing and incoming vertices.

[0090] In the disclosed embodiment, the vulnerability pattern library includes at least one of the following vulnerability patterns: Jsp Trojan, Sql injection, Servlet thread insecurity or server-side request forgery.

[0091] Among them, Jsp Trojan refers to injecting java code into Jsp code and using runtime command calling statements to allow the caller to execute any simple command on the server.

[0092] For example, the following network access request

[0093] http: / / localhost:9000 / javasec / commandExecution.jsp?command=whoami Accessing the service will execute the "whoami" command on the server interrupt. The attacker can replace the "whoami" command with any shell command as needed.

[0094] Sql injection is a primitive database information stealing attack, which takes advantage of the simple splicing vulnerability of the front-end SQL request and injects wildcards such as '%' into the request information (usually the user or password part) to achieve the purpose of unauthorized access to the database.

[0095] SSRF (Server-Side Request Forgery) is a security vulnerability that is constructed by an attacker to initiate a request from the server. Generally, the target of SSRF attacks is an internal system that cannot be accessed from the external network.

[0096] Servlet thread unsafe means that when a web container (such as tomcat) receives an http request from a client, it will take a thread from the thread pool and initialize the servlet object before calling the service method. It is important that the Servlet object is a singleton, that is, there is only one servlet instance object in the web container. If multiple http requests request the same servlet, multiple threads will be formed to call the same service method concurrently. If instance variables or static variables are defined in the servlet at this time, thread safety issues may occur.

[0097] Other typical vulnerability modes such as Servlet thread insecurity and SSRF are relatively popular, and their specific vulnerability modes will not be repeated in this disclosure.

[0098] Therefore, after the above one or several vulnerability patterns are pre-set according to the actual needs of the user, they are all added to the vulnerability pattern library, that is, the vulnerability pattern library is established.

[0099] In the disclosed embodiment, each node in the control flow graph is traversed according to a pre-created vulnerability pattern library, including: using a depth-first traversal algorithm to traverse the nodes, with the starting point of the traversal path being the start node, the end point of the traversal path being a node that matches any vulnerability pattern in the vulnerability pattern library, and synchronously recording all assignment statements and jump conditions on the traversal path.

[0100] Among them, the depth-first search algorithm, also known as DFS (Depth First Search), is a search algorithm, and the search algorithm is essentially an enumeration, that is, a method of using the high performance of computers to purposefully enumerate part of a problem or all of the problems of the problem, and then find a solution to the problem.

[0101] Figure 7 The schematic diagram shows a structural form of a vulnerability path constraint generated according to an embodiment of the present disclosure.

[0102] like Figure 7As shown, the vulnerability path constraint corresponding to the preset target defect generated in operation S202 of the embodiment of the present disclosure. In order to further avoid the false alarm of the unreachable path in the existing method and thus realize the path sensitive detection, the constraint solving is performed in operation S203 to determine the reachability of the target path.

[0103] In formal description, constraint problems are composed of the following three basic elements: variables V, domains of variables D, and constraints C. Each variable vi in ​​V corresponds to an element di in D, indicating that di is a possible set of values ​​of vi. Constraint C describes the relationship that must be satisfied between variables V. Solving constraint problems is to find a set of values ​​in the domains corresponding to each variable so that this set of values ​​meets the requirements of constraint C.

[0104] In the disclosed embodiment, the SMT solver is theorem solver Z3. Theorem solver Z3 uses SMI-LIBstandard syntax code as input, and returns whether the assignment and judgment in the input file are self-consistent.

[0105] In order to match the theorem solver Z3 solver, in the embodiment of the present disclosure, an infix conditional to prefix conditional algorithm or a prefix expression bracket generation algorithm is used to convert the vulnerability path constraint into the SMI-LIB standard form.

[0106] Figure 8 The structural form of the algorithm for converting an infix conditional expression to a prefix conditional expression according to an embodiment of the present disclosure is schematically shown.

[0107] like Figure 8 As shown, infix expressions are expressions where the operator is between operands, while prefix expressions are expressions where the operator is written in front and the operand is written in the back. In the algorithm for converting infix conditionals to prefix conditionals, in order to make the conversion correct, two stacks need to be set up, one for storing operators and the other for storing the results of the conversion. For the stack that stores operators, a special operator must first be placed at the bottom of the stack, assumed to be the '@' character, so that it has the lowest operator priority, assumed to be the value 0. This stack is used to store operators obtained by scanning infix expressions that cannot be temporarily placed in the stack for storing conversion results. After its two operands are placed in the stack that temporarily stores the conversion results, it is popped out of the stack and placed in the stack that stores the conversion results.

[0108] Fig. 9 The structural form of the prefix expression bracket generation algorithm according to the embodiment of the present disclosure is schematically shown.

[0109] like Fig. 9As shown, the prefix expression bracket generation algorithm means that given a prefix expression string, which may contain three types of brackets: "()", "{}", and "[]", please write a program to check whether the brackets of the string appear in pairs.

[0110] In the disclosed embodiment, after the step of performing SMT standard conversion on the vulnerability path constraints, it also includes: adding the SMI-LIB standard tail to the vulnerability path constraints after the SMT standard conversion to obtain a legal constraint set of the vulnerability path.

[0111] Specifically, after converting the vulnerability path constraints into the SMI-LIB standard format according to the above two algorithms, it is necessary to add the SMI-LIB standard tail to construct the vulnerability path legal constraint set. Then, after saving the vulnerability path legal constraint set, the command of the theorem solver Z3 can be used to solve the constraints.

[0112] When the command of the theorem solver Z3 is used to solve the constraint, the theorem solver Z3 can return the assignment in the input file and the judgment whether it is self-consistent. Therefore, the present disclosure can detect whether there is a security vulnerability in the accessible path of the vulnerability path during static detection, and can pre-screen and filter the unreachable path in advance, thereby effectively reducing the false alarm phenomenon of vulnerability detection and improving the detection accuracy.

[0113] Among them, an unreachable path means that if the suspicious point cannot be reached from each entry point in the search path, the code at the suspicious point cannot be used, so there is no copper leakage in the unreachable path, and the suspicious point can be excluded. On the contrary, for reachable suspicious points, saving all reachable path information and performing reachability analysis can reduce a certain false alarm rate, improve the efficiency of subsequent vulnerability detection work, and reduce the cost of data dependency analysis and dynamic verification.

[0114] Finally, for the reachable suspicious points, data flow tracking is performed by analyzing the incoming and outgoing data near the suspicious points to detect whether there are security vulnerabilities in the reachable path.

[0115] Fig.10 A block diagram of a program vulnerability detection device according to an embodiment of the present invention is schematically shown.

[0116] like Fig.10 As shown, the program vulnerability detection device 1000 may include a feature extraction module 1010 , a path constraint collection module 1020 , a path constraint solving module 1030 and a vulnerability detection module 1040 .

[0117] The feature extraction module 1010 is used to obtain program source code, extract intermediate codes in the program source code, and generate a control flow graph according to the intermediate codes;

[0118] The path constraint collection module 1020 is used to traverse each node in the control flow graph according to the pre-created vulnerability pattern library and collect vulnerability path constraints corresponding to the preset target defects;

[0119] A path constraint solving module 1030 is used to solve the vulnerability path constraint using an SMT solver after performing SMT standardization conversion on the vulnerability path constraint to determine whether the vulnerability path is reachable;

[0120] The vulnerability detection module 1040 is used to detect whether there is a security vulnerability in the accessible path in the vulnerability path when the vulnerability path is reachable; otherwise, filter out the unreachable path in the vulnerability path.

[0121] Fig.11A The block diagram of a feature extraction module according to an embodiment of the present invention is schematically shown.

[0122] like Fig.11A As shown, further, the feature extraction module 1010 may include an intermediate code extraction unit 1011 and a control flow graph generation unit 1012, wherein:

[0123] An intermediate code extraction unit 1011 is used to extract the intermediate code in the program source code by using the Soot framework, where the intermediate code is a Jimple format intermediate code;

[0124] The control flow graph generation unit 1012 is used to initialize an empty vertex set V and an empty edge set E; traverse each statement in the Jimple format intermediate code, create a new vertex for each statement, and add the new vertex to the empty vertex set V; traverse each statement in the Jimple format intermediate code, and determine whether each statement is a goto label jump statement. If so, add a first new edge in the empty edge set E, whose outgoing vertex is the new vertex of the goto label jump statement and whose incoming vertex is the new vertex corresponding to the label; otherwise, add a second new edge in the empty edge set E, whose outgoing vertex is the new vertex of the current statement and whose incoming vertex is the new vertex of the next statement of the current statement.

[0125] Fig. 11B The block diagram of the path constraint collection module according to the embodiment of the present invention is schematically shown.

[0126] like Fig. 11B As shown, further, the path constraint collection module 1020 may include a pattern matching unit 1021 and a synchronization recording unit 1022, wherein:

[0127] The pattern matching unit 1021 is used to perform node traversal using a depth-first traversal method, where the starting point of the traversal path is the start node, and the end point of the traversal path is a node that matches any vulnerability pattern in the vulnerability pattern library;

[0128] The synchronous recording unit 1022 is used to synchronously record all assignment statements and jump conditions on the traversal path.

[0129] Fig. 11C The block diagram of the path constraint solving module according to the embodiment of the present invention is schematically shown.

[0130] like Fig. 11C As shown, further, the path constraint solving module 1030 may include a path constraint conversion unit 1031 and a standard tail adding unit 1032, wherein:

[0131] A path constraint conversion unit 1031 is used to convert the vulnerability path constraint into an SMI-LIB standard form by using an infix conditional to prefix conditional method or a prefix expression bracket generation method;

[0132] The standard tail adding unit 1032 is used to add the SMI-LIB standard tail to the vulnerability path constraint in the SMI-LIB standard format to obtain a vulnerability path legal constraint set.

[0133] It should be noted that the device part in the embodiment of the present disclosure corresponds to the method part in the embodiment of the present disclosure. The description of the program vulnerability detection device part specifically refers to the program vulnerability detection method part, which will not be repeated here.

[0134] According to the embodiments of the present invention, any one or more of the modules, submodules, units, and subunits, or at least part of the functions of any one of them can be implemented in one module. According to the embodiments of the present invention, any one or more of the modules, submodules, units, and subunits can be split into multiple modules for implementation. According to the embodiments of the present invention, any one or more of the modules, submodules, units, and subunits can be at least partially implemented as hardware circuits, such as field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), systems on chips, systems on substrates, systems on packages, application specific integrated circuits (ASICs), or can be implemented by hardware or firmware in any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in any appropriate combination of any of them. Alternatively, according to the embodiments of the present invention, one or more of the modules, submodules, units, and subunits can be at least partially implemented as computer program modules, and when the computer program modules are run, the corresponding functions can be performed.

[0135] For example, any of the feature extraction module 1010, the path constraint collection module 1020, the path constraint solving module 1030, and the vulnerability detection module 1040 can be combined in one module / unit / sub-unit for implementation, or any of the modules / units / sub-units can be split into multiple modules / units / sub-units. Alternatively, at least part of the functions of one or more of these modules / units / sub-units can be combined with at least part of the functions of other modules / units / sub-units and implemented in one module / unit / sub-unit. According to an embodiment of the present disclosure, at least one of the feature extraction module 1010, the path constraint collection module 1020, the path constraint solving module 1030, and the vulnerability detection module 1040 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application specific integrated circuit (ASIC), or can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or by any one of the three implementation methods of software, hardware, and firmware, or by a suitable combination of any of them. Alternatively, at least one of the feature extraction module 1010, the path constraint collection module 1020, the path constraint solving module 1030 and the vulnerability detection module 1040 may be at least partially implemented as a computer program module, which may perform a corresponding function when executed.

[0136] Fig.12 The block diagram of an electronic device according to an embodiment of the present invention is schematically shown. Fig.12 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0137] like Fig.12 As shown, the electronic device 1200 includes a processor 1210 and a computer-readable storage medium 1220. The electronic device 1200 can execute the program vulnerability detection method according to the embodiment of the present disclosure.

[0138] Specifically, the processor 1210 may include, for example, a general-purpose microprocessor, an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1210 may also include an onboard memory for cache purposes. The processor 1210 may be a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0139] Computer-readable storage medium 1220, for example, can be a non-volatile computer-readable storage medium, and specific examples include but are not limited to: magnetic storage devices, such as magnetic tapes or hard disks (HDD); optical storage devices, such as compact disks (CD-ROMs); memories, such as random access memories (RAMs) or flash memories; and the like.

[0140] The computer-readable storage medium 1220 may include a computer program 1221 , which may include code / computer-executable instructions that, when executed by the processor 1210 , cause the processor 1210 to perform a method according to an embodiment of the present disclosure or any variation thereof.

[0141] The computer program 1221 may be configured to have, for example, a computer program code including a computer program module. For example, in an example embodiment, the code in the computer program 1221 may include one or more program modules, for example, including 1221A, module 1221B, ... It should be noted that the division method and number of modules are not fixed, and those skilled in the art may use appropriate program modules or program module combinations according to actual conditions, and when these program module combinations are executed by the processor 1210, the processor 1210 may execute the method according to the embodiment of the present disclosure or any variation thereof.

[0142] According to an embodiment of the present disclosure, at least one of the feature extraction module 1010, the path constraint collection module 1020, the path constraint solving module 1030, and the vulnerability detection module 1040 may be implemented as a reference. Fig.12 The computer program modules described above, when executed by the processor 1210, can implement the corresponding operations described above.

[0143] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the program vulnerability detection method according to the embodiment of the present disclosure is implemented.

[0144] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the above-mentioned module, program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should be noted that each square box in the block diagram or flow chart, and the combination of the square boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0145] It will be appreciated by those skilled in the art that the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways, even if such combinations and / or combinations are not explicitly described in the present disclosure. In particular, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways without departing from the spirit and teachings of the present disclosure. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0146] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A program vulnerability detection method, comprising: Obtaining program source code, extracting intermediate code from the program source code, and generating a control flow graph according to the intermediate code; According to the pre-created vulnerability pattern library, traverse each node in the control flow graph to collect vulnerability path constraints corresponding to preset target defects; After performing SMT standardization conversion on the vulnerability path constraint, the vulnerability path constraint is solved using an SMT solver to determine whether the vulnerability path is reachable; If yes, then checking whether there is a security vulnerability in the accessible path in the vulnerability path; Otherwise, filter out the unreachable paths in the vulnerability path; The step of obtaining the program source code and extracting the intermediate code from the program source code includes: The program source code is Java bytecode, and the intermediate code in the program source code is extracted using the Soot framework, and the extracted intermediate code includes at least one of Baf, Jimple, Shimple or Grimp format intermediate codes; The intermediate code is a Jimple format intermediate code, and the Jimple format intermediate code in the program source code is extracted using the Soot framework, and the method includes: All variables in the program source code are declared at the beginning of Jimple; constant data in the program source code is converted into byte data; method calls in the program source code are prefixed with virtualinvoke or staticinvoke; control flows in the program source code are expressed with goto label jump statements; The step of generating a control flow graph according to the intermediate code comprises: Initialize an empty vertex set V and an empty edge set E; traverse each statement in the Jimple format intermediate code, create a new vertex for each statement, and add the new vertex to the empty vertex set V; traverse each statement in the Jimple format intermediate code, determine whether each statement is the goto label jump statement, if so, add a first new edge in the empty edge set E, whose outgoing vertex is the new vertex of the goto label jump statement and whose incoming vertex is the new vertex corresponding to the label; otherwise, add a second new edge in the empty edge set E, whose outgoing vertex is the new vertex of the current statement and whose incoming vertex is the new vertex of the next statement of the current statement.

2. The program vulnerability detection method according to claim 1, wherein: The vulnerability pattern library includes at least one of the following vulnerability patterns: Jsp Trojan, Sql injection, Servlet thread insecurity or server-side request forgery.

3. The program vulnerability detection method according to claim 2, wherein: The step of traversing each node in the control flow graph according to the pre-created vulnerability pattern library includes: A depth-first traversal algorithm is used to traverse nodes, the starting point of the traversal path is the start node, the end point of the traversal path is a node that matches any vulnerability pattern in the vulnerability pattern library, and all assignment statements and jump conditions on the traversal path are synchronously recorded.

4. The program vulnerability detection method according to claim 1, wherein: The performing SMT standardization conversion on the vulnerability path constraint includes: The vulnerability path constraint is converted into the SMI-LIB standard form by using an infix conditional-to-prefix conditional algorithm or a prefix expression bracket generation algorithm.

5. The program vulnerability detection method according to claim 4, wherein: The SMT solver is theorem solver Z3. After the step of performing SMT standardization conversion on the vulnerability path constraint, the method further includes: The SMI-LIB standard tail is added to the vulnerability path constraint after the SMT standardization conversion to obtain a vulnerability path legal constraint set.

6. A program vulnerability detection device, comprising: A feature extraction module is used to obtain program source code, extract intermediate code from the program source code, and generate a control flow graph according to the intermediate code; The feature extraction module also includes: An intermediate code extraction unit, used for extracting the intermediate code in the program source code by using the Soot framework, wherein the intermediate code is a Jimple format intermediate code; A control flow graph generation unit is used to initialize an empty vertex set V and an empty edge set E; traverse each statement in the Jimple format intermediate code, create a new vertex for each statement, and add the new vertex to the empty vertex set V; traverse each statement in the Jimple format intermediate code, determine whether each statement is a goto label jump statement, if yes, add a first new edge in the empty edge set E, whose outgoing vertex is a new vertex of the goto label jump statement and whose incoming vertex is a new vertex corresponding to the label; otherwise, add a second new edge in the empty edge set E, whose outgoing vertex is a new vertex of the current statement and whose incoming vertex is a new vertex of the next statement of the current statement; A node traversal module, used to traverse each node in the control flow graph according to a pre-created vulnerability pattern library, and collect vulnerability path constraints corresponding to preset target defects; An SMT solving module, configured to perform SMT standardization conversion on the vulnerability path constraint, solve the vulnerability path constraint using an SMT solver, and determine whether the vulnerability path is reachable; and The vulnerability detection module is used to detect whether there is a security vulnerability in the accessible path in the vulnerability path when the vulnerability path is reachable; otherwise, filter out the unreachable path in the vulnerability path.

7. The program vulnerability detection device according to claim 6, wherein: The node traversal module also includes: A pattern matching unit, used for performing node traversal using a depth-first traversal algorithm, wherein the starting point of the traversal path is a start node, and the end point of the traversal path is a node matching any vulnerability pattern in the vulnerability pattern library; The synchronization recording unit is used to synchronously record all assignment statements and jump conditions on the traversal path.

8. The program vulnerability detection device according to claim 6, wherein: The SMT solving module also includes: A path constraint conversion unit, used to convert the vulnerability path constraint into an SMI-LIB standard form by using an infix conditional to prefix conditional algorithm or a prefix expression bracket generation algorithm; The standard tail adding unit is used to add the SMI-LIB standard tail to the vulnerability path constraint in the SMI-LIB standard format to obtain a vulnerability path legal constraint set.

9. An electronic device, comprising: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 5.

10. A computer-readable storage medium storing computer-executable instructions, wherein the instructions are used to implement the method according to any one of claims 1 to 5 when executed.

Images