CN113312618A - Program vulnerability detection method and device, electronic equipment and medium - Google Patents

Abstract

The disclosure provides a program vulnerability detection method, device, electronic equipment and medium, and relates to the field of network security or financial science and technology. The program vulnerability detection method comprises the following steps: acquiring a program source code, extracting an intermediate code in the program source code, and generating a control flow graph according to the intermediate code; traversing each node in a control flow graph according to a pre-established vulnerability mode library, and collecting vulnerability path constraints corresponding to preset target defects; after SMT standard conversion is carried out on the loophole path constraint, an SMT solver is used for solving the loophole path constraint, and whether the loophole path can be reached is judged; if yes, detecting whether a security vulnerability exists in a reachable path in the vulnerability path; otherwise, filtering an unreachable path in the vulnerability path.

Description

Program vulnerability detection method and device, electronic equipment and medium

Technical Field

The present disclosure relates to the field of network security or financial technology, and in particular, to a method and an apparatus for detecting program vulnerabilities, an electronic device, and a medium.

Background

Program vulnerabilities are one of the main root causes of information security risks and are important targets in network defense and attack. The detection and mining of program vulnerabilities or software vulnerabilities have been a research hotspot in academic and financial fields, and the main detection methods thereof are divided into two types: one is vulnerability static detection and mining based on software source code; the other method is a source code vulnerability detection method based on deep learning.

The vulnerability static detection method based on the software source code constructs a behavior set of a software control flow through a static analysis technology, obtains a real-time verification value of each judgment block in the software execution process, compares and verifies the real-time verification value with a software control flow behavior feature set in real time, and outputs a software vulnerability detection result. However, the static vulnerability detection method is based on the abnormality of the control flow of the program itself, and cannot detect the defect that the control flow of the program is not changed, and if some external attack only affects the numerical value of the program variable (the change of key variables such as money amount and the like), the detection cannot be carried out; in addition, the vulnerability static detection method is actually a dynamic detection scheme, and verification in the execution process inevitably affects the program performance.

The source code vulnerability detection method based on deep learning can automatically complete feature extraction of the source code and construct a vulnerability detection model to perform vulnerability detection on the program. However, on one hand, the source code vulnerability detection method lacks a preprocessing process, an abstract syntax tree, a control flow graph and a program dependence graph are the most important structural elements of a program, the semantic dimension of the method is wide and complex, and the method needs to rely on the interpretation capability of a classifier; on the other hand, the sample is difficult to obtain, and on the premise that the feature vector is a spliced high-dimensional vector, it is a high-cost and difficult task to obtain enough and reasonably distributed vulnerability programs and label the vulnerability programs; there is also the drawback of insufficient interpretability.

Disclosure of Invention

In view of the above deficiencies of the prior art, the present disclosure provides a method, an apparatus, an electronic device, and a medium for detecting program vulnerabilities, so as to solve the problems that, in the current program vulnerability detection, a defect that a program control flow is not changed cannot be detected and program performance is affected in verification of a dynamic detection execution process.

One aspect of the present disclosure provides a program vulnerability detection method, including: acquiring a program source code, extracting an intermediate code in the program source code, and generating a control flow graph according to the intermediate code; traversing each node in a control flow graph according to a pre-established vulnerability mode library, and collecting vulnerability path constraints corresponding to preset target defects; after SMT standard conversion is carried out on the loophole path constraint, an SMT solver is used for solving the loophole path constraint, and whether the loophole path can be reached is judged; if yes, detecting whether a security vulnerability exists in a reachable path in the vulnerability path; otherwise, filtering an unreachable path in the vulnerability path.

According to the embodiment of the disclosure, acquiring a program source code, and extracting an intermediate code in the program source code, includes: the program source code is Java byte code, and the intermediate code in the program source code is extracted by using a Soot framework, wherein the extracted intermediate code comprises at least one of intermediate codes in Baf, Jimple, Shimple or Grimp formats.

According to the embodiment of the disclosure, the intermediate code is a Jimple format intermediate code, the Jimple format intermediate code in the program source code is extracted by using a Soot framework, and the method comprises the following steps: variables in program source code are all declared at the beginning of a Jimple; converting constant data in a program source code into byte type data; the method call in the program source code takes virtualinvoke or staticiinvoke as a prefix; the control flows in the program source code are all expressed by goto label jump statements.

According to an embodiment of the present disclosure, generating a control flow graph according to a midamble includes: initializing a null vertex set V and a null edge set E; traversing each statement in the Jimple format intermediate code, creating a new vertex for each statement, and adding the new vertex into the empty vertex set V; traversing each statement in the intermediate code in the Jimple format, judging whether each statement is a goto label jump statement, if so, adding a vertex which is a new vertex of the goto label jump statement and an input vertex which is a first new edge of a label corresponding to the new vertex in the empty edge set E; otherwise, adding a second new edge with a vertex being a new vertex of the current statement and an incoming vertex being a new vertex of a next statement of the current statement in the empty edge set E.

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 insecure or server side request forgery.

According to the embodiment of the disclosure, traversing each node in a control flow graph according to a pre-created vulnerability pattern library comprises: and performing node traversal by adopting a depth-first traversal algorithm, wherein the starting point of a traversal path is a starting node, the end point of the traversal path is a node matched with any vulnerability pattern in the vulnerability pattern library, and all assignment statements and jump conditions on the traversal path are synchronously recorded.

According to the embodiment of the disclosure, the SMT standardization conversion of the vulnerability path constraint includes: and converting the vulnerability path constraint into an SMI-LIB standard form by adopting a infix conditional prefix-to-prefix conditional algorithm or a prefix expression bracket generation algorithm.

According to the embodiment of the disclosure, the SMT solver is a theorem solver Z3, and after the step of performing SMT standardized conversion on the vulnerability path constraint, the method further includes: and adding an SMI-LIB standard tail part to the vulnerability path constraint after SMT standardization conversion to obtain a vulnerability path legal constraint set.

Another aspect of the present disclosure provides a program vulnerability detection apparatus, including: the characteristic extraction module is used for acquiring a program source code, extracting an intermediate code in the program source code and generating a control flow graph according to the intermediate code; the node traversing module is used for traversing each node in the control flow graph according to a pre-established vulnerability mode library and collecting vulnerability path constraints corresponding to preset target defects; the SMT solving module is used for solving the vulnerability path constraint by using an SMT solver after SMT standard conversion is carried out on the vulnerability path constraint, and judging whether the vulnerability path can be reached or not; the vulnerability detection module is used for detecting whether the accessible paths in the vulnerability paths have security vulnerabilities when the vulnerability paths are accessible; otherwise, filtering an unreachable path in the vulnerability path.

According to an embodiment of the present disclosure, the feature extraction module further includes: the intermediate code extracting unit is used for extracting an intermediate code in the program source code by using a Soot framework, wherein the intermediate code is a Jimple format intermediate code; the control flow graph generating unit is used for initializing a null vertex set V and a null edge set E; traversing each statement in the Jimple format intermediate code, creating a new vertex for each statement, and adding the new vertex into the empty vertex set V; traversing each statement in the intermediate code in the Jimple format, judging whether each statement is a goto label jump statement, if so, adding a vertex which is a new vertex of the goto label jump statement and an input vertex which is a first new edge of a label corresponding to the new vertex in the empty edge set E; otherwise, adding a second new edge with a vertex being a new vertex of the current statement and an incoming vertex being a new vertex of a next statement of the current statement in the empty edge set E.

According to an embodiment of the present disclosure, the node traversal module further includes: the pattern matching unit is used for traversing nodes by adopting a depth-first traversal algorithm, wherein the starting point of a traversal path is a starting node, and the end point of the traversal path is a node matched with any vulnerability pattern in the vulnerability pattern library; and the synchronous recording unit is used for synchronously recording all assignment statements and jump conditions on the traversal path.

According to an embodiment of the present disclosure, the SMT solution module further includes: the path constraint conversion unit is used for converting the vulnerability path constraint into an SMI-LIB standard form by adopting a infix conditional prefix conversion conditional algorithm or a prefix expression bracket generation algorithm; and the standard tail adding unit is used for adding an SMI-LIB standard tail to the vulnerability path constraint in the SMI-LIB standard form to obtain a vulnerability path legal constraint set.

Another aspect of the present disclosure provides an electronic device including: one or more processors; a storage device to store one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method as described above.

Another aspect of the present disclosure provides a computer-readable storage medium storing computer-executable instructions for implementing the method as described above when executed.

Another aspect of the disclosure provides a computer program comprising computer executable instructions for implementing the method as described above when executed.

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

(1) the invention provides a brand-new method for generating an IR flow chart based on Jimple IR, which provides a reliable basis for subsequent vulnerability path search and can lock a vulnerability range at a line level;

(2) according to the method, the path constraint in the IR form is automatically converted into a constraint set conforming to the syntax of Microsoft z3 SMI-LIB standard, so that the loophole path is constrained and solved, the defect detection of path sensitivity is achieved, and the error identification is reduced;

(3) the method and the device can realize interpretable static vulnerability detection at program flow, function and method levels in program vulnerability detection;

(4) the program vulnerability detection method and device improve detection efficiency, high recall and high precision rate of program vulnerability detection.

Drawings

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

fig. 1 schematically illustrates an exemplary system architecture of a program vulnerability detection method and apparatus according to an embodiment of the present disclosure;

FIG. 2 is a flow chart schematically illustrating a program vulnerability detection method according to an embodiment of the present disclosure;

FIG. 3 is a flowchart illustrating the operation of a program vulnerability detection method according to an embodiment of the present disclosure;

FIG. 4 schematically illustrates an operational flow diagram for extracting a Jimple format midamble using a Soot framework, in accordance with an embodiment of the present disclosure;

FIG. 5 schematically illustrates an operational procedure for generating a control flow graph from a Jimple format intermediate code, according to an embodiment of the present disclosure;

FIG. 6 schematically illustrates a structural form of a control flow graph generated according to an embodiment of the present disclosure;

FIG. 7 schematically illustrates a structural form of a vulnerability path constraint generated according to an embodiment of the present disclosure;

fig. 8 schematically shows a structural form of a infix conditional prefix-over-prefix conditional algorithm according to an embodiment of the present disclosure;

FIG. 9 schematically illustrates a structural form of a prefix expression bracket generation algorithm according to an embodiment of the present disclosure;

FIG. 10 is a block diagram that schematically illustrates an apparatus for program vulnerability detection, in accordance with an embodiment of the present invention;

FIG. 11A schematically shows a block diagram of a feature extraction module according to an embodiment of the present invention;

FIG. 11B schematically illustrates a block diagram of a path constraint collection module, according to an embodiment of the invention;

FIG. 11C schematically illustrates a block diagram of a path constraint solving module, in accordance with an embodiment of the present invention; and

FIG. 12 schematically shows a block diagram of an electronic device according to an embodiment of the disclosure.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is illustrative only and is not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.

Where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.). Where a convention analogous to "A, B or at least one of C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).

Some block diagrams and/or flow diagrams are shown in the figures. It will be understood that some blocks of the block diagrams and/or flowchart illustrations, or combinations thereof, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the instructions, which execute via the processor, create means for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks. The techniques of this disclosure may be implemented in hardware and/or software (including firmware, microcode, etc.). In addition, the techniques of this disclosure may take the form of a computer program product on a computer-readable storage medium having instructions stored thereon for use by or in connection with an instruction execution system.

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

Ir (mediate reproduction): the intermediate expression form, or intermediate code, specifically the LLVM intermediate representation, is an intermediate language of LLVM. Wherein the LLVM item is a modular, reusable set of compilers and tool chains.

A Control Flow Graph (CFG), also called a Control flow graph, is an abstract representation of a process or program, is an abstract data structure used in a compiler, is maintained internally by the compiler, and represents all paths traversed during the execution of a program. The method can graphically represent the possible flow direction of all basic block execution in a process and can also reflect the real-time execution process of the process.

A Soot frame: the Java bytecode optimization framework is an open source Java bytecode optimization framework developed by a Sable research group of McGill university, can convert class files generated by Java compilation into the intermediate representation of Soot, provides extensible analysis frameworks such as analysis, optimization, decompilation and annotation of the bytecode files for users, and can be used by analysts to analyze Java codes by means of Soot.

And (3) an SMT solver: the full name is the Satisfibability Module tools, and the Satisfibability module tools can be translated into Satisfiability model theory, Satisfiability problem under multiple Theories or Satisfiability problem under specific (background) Theories, and the judgment algorithm is called an SMT solver. Briefly, an SMT formula is a logical formula that incorporates a theoretical background, where propositional variables may represent the theoretical formula.

Theorem proving instrument Z3: the SMT solver is an open source constraint SMT solver developed by Microsoft corporation and can check the satisfiability of a logic expression. Theorem prover Z3 provides an attractive match for software analysis and validation tools because several common software constructs map directly into supporting theories. Theorem proves that the input format of the Z3 is an extension of the SMT-LIB2.0 standard, and a Z3 script is a command sequence.

The embodiment of the disclosure provides a program bug detection method and device. The method comprises the following steps: acquiring a program source code, extracting an intermediate code in the program source code, and generating a control flow graph according to the intermediate code; traversing each node in a control flow graph according to a pre-established vulnerability mode library, and collecting vulnerability path constraints corresponding to preset target defects; after SMT standard conversion is carried out on the loophole path constraint, an SMT solver is used for solving the loophole path constraint, and whether the loophole path can be reached is judged; if yes, detecting whether a security vulnerability exists in a reachable path in the vulnerability path; otherwise, filtering an unreachable path in the vulnerability path.

Fig. 1 schematically illustrates an exemplary system architecture 100 in which the method and apparatus for application vulnerability detection may be implemented, according to an embodiment of the present disclosure. It should be noted that fig. 1 is only an example of a system architecture to which the embodiments of the present disclosure may be applied to help those skilled in the art understand the technical content of the present disclosure, and does not mean that the embodiments of the present disclosure may not be applied to other devices, systems, environments or scenarios.

As shown in fig. 1, 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 serves as a medium for providing communication links between the terminal devices 101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired and/or wireless communication links, and so forth.

The user may use the terminal devices 101, 102, 103 to interact with the server 105 via the network 104 to receive or send messages or the like.

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

The server 105 may be a server providing various services, such as a background management server (for example only) providing support for websites browsed by users using the terminal devices 101, 102, 103.

It should be noted that the program bug detection method provided by the embodiment of the present disclosure may be generally executed by the server 105. Accordingly, the program bug detection apparatus provided by the embodiments of the present disclosure may be generally disposed in the server 105. The program vulnerability detection method provided by the embodiment of the present disclosure may also be executed by a server or a server cluster which is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and/or the server 105. Accordingly, the program bug detection apparatus provided by the embodiment of the present disclosure may also be disposed in a server or a server cluster different from the server 105 and capable of communicating with the terminal devices 101, 102, 103 and/or the server 105.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Fig. 2 schematically shows a flowchart of a program vulnerability detection method according to an embodiment of the present disclosure.

As shown in fig. 2, the program bug detection method may include operations S201 to S203.

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

In operation S202, each node in the control flow graph is traversed according to a pre-created vulnerability pattern library, and vulnerability path constraints corresponding to a preset target vulnerability are collected.

In operation S203, after performing SMT standard conversion on the vulnerability path constraints, an SMT solver is used to solve the vulnerability path constraints, and whether the vulnerability path is reachable is determined.

In operation S204, if yes, detecting whether a security vulnerability exists in a reachable path in the vulnerability path; otherwise, filtering an unreachable path in the vulnerability path.

According to the embodiment of the disclosure, a vulnerability pattern library is established as a vulnerability detection standard, suspicious path search is performed by combining intermediate code IR extraction and control flow graph generation of a program source code, and flow sensitivity and path sensitivity screening of suspicious paths are completed by combining path constraint collection and constraint solving, so that a high-check and high-precision program vulnerability detection effect is realized.

Fig. 3 schematically illustrates an operation flowchart of a program vulnerability detection method according to an embodiment of the present disclosure.

As shown in fig. 3, in the embodiment of the present disclosure, the program source code is Java bytecode, and the boot framework is used to extract intermediate code in the program source code, where the extracted intermediate code includes at least one of Baf, Jimple, Shimple, and Grimp format intermediate code.

For example, the present disclosure employs a Soot framework, developed by Sable research team of McGill University, that was originally designed to optimize Java bytecodes for mid-code IR extraction. For the incoming Java bytecode, the Soot framework provides four different levels of midamble IR extraction: baf, Jimple, Shimple, and Grimp.

Wherein: the Baf intermediate code is an instruction set based on stack operation, and the intermediate representation is the simplest; the Jimple intermediate code is the core of the Soot framework, is the most important of the four kinds of IR, and is a typed, three-address and statement-based intermediate code; the ShimpleMeddress is a static single-assignment (SSA) Jimple representation version; the Grimp intermediate code can construct a tree structure, is closer to java source code, is suitable for disassembling and is convenient to read.

Since the most common of the socket frames is Jimple, the intermediate code extracted by the present disclosure may adopt a Jimple format intermediate code, for example. The expression of the intermediate code in the Jimple format is a three-address-code expression, and each instruction at most comprises three variables; and the Jimple only contains 15 instructions, which is more beneficial to analysis than Java byte codes.

It is understood that, in other embodiments, the intermediate code in Baf, Shimple, or Grimp format may also be used for IR extraction, and the specific IR extraction steps are not described in detail in this disclosure.

Fig. 4 schematically shows an operation flowchart for extracting a Jimple format intermediate code by using a Soot framework according to an embodiment of the present disclosure.

As shown in fig. 4, extracting Jimple format intermediate code in program source code using the Soot framework may include sub-operations S401 to S404.

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

In operation S402, constant data in the program source code is converted into byte-type data.

In operation S403, method calls in the program source code are all prefixed by virtualinvoke or staticiinvoke.

The virtualinvoke is used for calling an object method in an instantiation object, and the virtualinvoke can perform method searching according to the current actual object type and sequentially search upwards according to inheritance or implementation hierarchy until a method closest to the current implementation class is found. statinvoke is actually a class-oriented instruction, and for a class loaded into jvm, the class variables, the load of static methods or the execution of static code blocks, which actually modify the relevant static in the class during execution, are loaded according to the class file loading process. It can be seen that virtualinvoke or staticiinvoke are actually different instructions for object methods and class methods.

In operation S404, control flows in the program source code are each expressed in a goto label jump statement.

It should be noted that there is no obvious sequence in the foregoing sub-operations S401 to S404, fig. 4 only lists an optional intermediate code extraction processing sequence, and in other embodiments, the sequence of the sub-operations S401 to S404 may be changed according to the actual needs of the user, which is not limited in this disclosure.

Through the sub-operations S401 to S404, the embodiment of the present disclosure can provide great convenience for subsequent Java file data stream and control stream analysis.

Fig. 5 schematically illustrates an operational procedure for generating a control flow graph from a Jimple format intermediate code according to an embodiment of the present disclosure.

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

In operation S501, initializing a null vertex set V and a null edge set E;

in operation S502, 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;

in operation S503, traversing each statement in the Jimple format intermediate code, and determining whether each statement is a goto label jump statement, if yes, adding a vertex in the empty edge set E as a new vertex of the goto label jump statement, and an incoming vertex as a first new edge of a label corresponding to the new vertex; otherwise, adding a second new edge with a vertex being a new vertex of the current statement and an incoming vertex being a new vertex of a next statement of the current statement in the empty edge set E.

Since the goto label jump statement corresponds to any control flow in the program source file, the disclosed embodiments can complete flow sensitive screening of suspected vulnerability paths.

Fig. 6 schematically shows a structural form of a control flow graph generated according to an embodiment of the present disclosure.

As shown in FIG. 6, the { ifi3 ≦ i2 goto label10} statement in the lower right corner is the goto label jump statement, which is the outgoing vertex added in the empty edge set E, and { label 10: return "" is a label corresponding statement, which is an input vertex matched with the above-mentioned output vertex added in the empty edge set E, and a first new edge is determined based on the output vertex and the input vertex matched with each other.

In 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 insecure or server side request forgery.

Where Jsp Trojan means that injecting java code in Jsp code and using a runtime command invocation statement will allow the caller to execute any simple command at the server.

For example, the following network access request

http:// localhost: jspcommand executes a "whoami" command on the server interrupt, which the attacker can replace with any shell command as required.

The Sq1 injection is an original database information stealing attack, and achieves the purposes of unauthorized access to a database and the like by injecting wildcards such as '%' and the like into request information (often a user or password part) by utilizing a simple splicing vulnerability of a front end to an sql request.

SSRF (Server-Side Request Forgery) is a security hole constructed by an attacker to form a Request initiated by a Server. In general, SSRF attacks target internal systems that are inaccessible from external networks.

It is not secure for Servlet threads, which means that when a web container (e.g., tomcat) receives a client http request, the web container calls the service method after fetching a thread from the thread pool and initializing a Servlet object. It is important that the Servlet object be a singleton schema, i.e., there is only one Servlet instance object in the web container. If multiple http requests (requests) request the same servlet, multiple threads may be formed to call the same service method at the same time, and if instance variables or static variables are defined in the servlet at this time, thread security problems may occur.

Other typical vulnerability models, such as Servlet thread insecure, SSRF, etc., are popular, and details of the vulnerability models are not repeated in this disclosure.

Therefore, after one or more vulnerability modes are preset according to the actual needs of the user, all the vulnerability modes are added into the vulnerability mode library, namely the vulnerability mode library is established.

In the embodiment of the present disclosure, traversing each node in a control flow graph according to a pre-created vulnerability pattern library includes: and performing node traversal by adopting a depth-first traversal algorithm, wherein the starting point of a traversal path is a starting node, the end point of the traversal path is a node matched with any vulnerability pattern in the vulnerability pattern library, and all assignment statements and jump conditions on the traversal path are synchronously recorded.

The depth First search algorithm, also called dfs (depth First search), is a search algorithm, and the search algorithm is essentially an enumeration method, that is, a method for purposefully enumerating some cases of a problem or all cases of the problem by means of high performance of a computer, and further solving the problem.

Fig. 7 schematically shows a structural form of a vulnerability path constraint generated according to an embodiment of the present disclosure.

As shown in fig. 7, the vulnerability path constraint corresponding to the preset target flaw is generated in operation S202 in the embodiment of the present disclosure. In order to further avoid the false alarm of the unreachable path in the existing method and thus implement the path sensitivity detection, a constraint solution is performed in operation S203 to determine the reachability of the target path.

In the formal description, the constraint problem consists of three basic elements: variable V, domain D of the variable, and constraint C. The variable vi in each V corresponds to an element di in D, indicating that di is a possible value set of vi. Constraint C describes the relationship that must be satisfied between variables V. Solving the constraint problem is to find a group of values in the value domain corresponding to each variable, so that the group of values meets the requirements in the constraint C.

In the embodiment of the disclosure, the SMT solver is a theorem solver Z3. The theorem solver Z3 adopts SMI-LIB standard grammar code as input, and returns assignment in the input file and judges whether the input file can be contradicted by itself.

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

Fig. 8 schematically shows a structural form of the infix conditional prefix-change conditional algorithm according to an embodiment of the present disclosure.

As shown in fig. 8, the infix expression is that the operator is in the middle of the operand, and the prefix expression means that the operator is written before and the operand is written after. In the infix conditional prefix-to-prefix conditional algorithm, in order to make the conversion correct, two stacks are required to be set, one is used for storing operators, and the other is used for storing results obtained by the conversion. For the stack storing operators, a special operator is put at the bottom of the stack, which is assumed to be '@' character, so that the special operator has the lowest operator priority and is assumed to be 0. The stack is used for storing an operator which is obtained by scanning the infix expression and can not be temporarily put into the stack for storing the conversion result, and after two operation objects of the operator are put into the stack for temporarily storing the conversion result, the operator is popped out of the stack and is put into the stack for storing the conversion result.

Fig. 9 schematically shows a structural form of a prefix expression bracket generation algorithm according to an embodiment of the present disclosure.

As shown in fig. 9, the prefix expression bracket generation algorithm means that, given a prefix expression string, three brackets of "()", "{ }", "[ ]" may be included inside, and please the writer check whether the brackets of the string appear in pairs.

In the embodiment of the present disclosure, after the step of performing SMT standardized conversion on the vulnerability path constraint, the method further includes: and adding an SMI-LIB standard tail part to the vulnerability path constraint after SMT standardization conversion to obtain a vulnerability path legal constraint set.

Specifically, after SMI-LIB standard form conversion is carried out on the vulnerability path constraint according to the two algorithms, an SMI-LIB standard tail part is added to construct a vulnerability path legal constraint set. Then, after the vulnerability path legal constraint set is saved, constraint solving can be performed by adopting a command of a theorem solver Z3.

When the constraint solving is performed by using the command of the theorem solver Z3, the theorem solver Z3 can return the assignment in the input file and judge whether the assignment can be performed by self. Therefore, the method and the device can simply detect whether the accessible paths in the vulnerability paths have security vulnerabilities during static detection, and can pre-screen and filter the inaccessible paths in advance, so that the false alarm phenomenon of vulnerability detection is effectively reduced, and the detection accuracy is improved.

The unreachable path means that if the suspicious point cannot be reached from each entry point in the search path, the codes at the suspicious point cannot be used, so that no copper leakage exists in the unreachable path, and the suspicious point can be eliminated. On the contrary, for reachable suspicious points, all reachable path information is stored, and reachability analysis is performed, so that a certain false alarm rate can be reduced, the working efficiency of subsequent vulnerability detection is improved, and the cost of data dependence analysis and dynamic verification is reduced.

And finally, for the reachable suspicious point, carrying out data flow tracking by analyzing the data transmitted in and out nearby the suspicious point, thereby detecting whether the reachable path has a security hole.

Fig. 10 is a block diagram schematically illustrating a program vulnerability detection apparatus according to an embodiment of the present invention.

As shown in fig. 10, the program vulnerability detection apparatus 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.

The feature extraction module 1010 is configured to obtain a program source code, extract an intermediate code in the program source code, and generate a control flow graph according to the intermediate code;

a path constraint collection module 1020, configured to traverse each node in the control flow graph according to a pre-created vulnerability pattern library, and collect vulnerability path constraints corresponding to a preset target flaw;

the path constraint solving module 1030 is configured to perform SMT standardized conversion on the vulnerability path constraints, then solve the vulnerability path constraints by using an SMT solver, and determine whether the vulnerability path is reachable;

the vulnerability detection module 1040 is configured to detect whether a security vulnerability exists in an accessible path in the vulnerability path when the vulnerability path is accessible; otherwise, filtering an unreachable path in the vulnerability path.

FIG. 11A schematically shows a block diagram of a feature extraction module according to an embodiment of the present invention.

As shown in fig. 11A, further, the feature extraction module 1010 may include a midamble extraction unit 1011 and a control flow graph generation unit 1012, wherein:

a middle code extracting unit 1011, configured to extract a middle code in the program source code by using a root framework, where the middle code is a Jimple format middle code;

a control flow graph generating unit 1012, configured to initialize a null vertex set V and a null edge set E; traversing each statement in the Jimple format intermediate code, creating a new vertex for each statement, and adding the new vertex into the empty vertex set V; traversing each statement in the intermediate code in the Jimple format, judging whether each statement is a goto label jump statement, if so, adding a vertex which is a new vertex of the goto label jump statement and an input vertex which is a first new edge of a label corresponding to the new vertex in the empty edge set E; otherwise, adding a second new edge with a vertex being a new vertex of the current statement and an incoming vertex being a new vertex of a next statement of the current statement in the empty edge set E.

FIG. 11B schematically shows a block diagram of a path constraint collection module according to an embodiment of the invention.

As shown in fig. 11B, further, the path constraint collection module 1020 may include a pattern matching unit 1021 and a synchronization recording unit 1022, wherein:

the pattern matching unit 1021 is used for performing node traversal by adopting a depth-first traversal method, wherein the starting point of a traversal path is a starting node, and the end point of the traversal path is a node matched with any vulnerability pattern in the vulnerability pattern library;

and the synchronous recording unit 1022 is used for synchronously recording all the assignment statements and the jump conditions on the traversal path.

FIG. 11C schematically shows a block diagram of a path constraint solving module, according to an embodiment of the invention.

As shown in fig. 11C, further, the path constraint solving module 1030 may include a path constraint transformation unit 1031 and a standard tail adding unit 1032, wherein:

a path constraint converting unit 1031, configured to convert the vulnerability path constraint into an SMI-LIB standard form by using a infix conditional prefix-to-prefix conditional method or a prefix expression bracket generating method;

and the standard tail adding unit 1032 is used for adding an SMI-LIB standard tail to the vulnerability path constraint in the SMI-LIB standard to obtain a vulnerability path legal constraint set.

It should be noted that the apparatus portion in the embodiment of the present disclosure corresponds to the method portion in the embodiment of the present disclosure, and the description of the program bug detection apparatus portion specifically refers to the program bug detection method portion, which is not described herein again.

Any number of modules, sub-modules, units, sub-units, or at least part of the functionality of any number thereof according to embodiments of the present disclosure may be implemented in one module. Any one or more of the modules, sub-modules, units, and sub-units according to the embodiments of the present disclosure may be implemented by being split into a plurality of modules. Any one or more of the modules, sub-modules, units, sub-units according to embodiments of the present disclosure may be implemented at least in part 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 may be implemented in any other reasonable manner of hardware or firmware by integrating or packaging a circuit, or in any one of or a suitable combination of software, hardware, and firmware implementations. Alternatively, one or more of the modules, sub-modules, units, sub-units according to embodiments of the disclosure may be at least partially implemented as a computer program module, which when executed may perform the corresponding functions.

For example, any plurality 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 combined and implemented in one module/unit/subunit, or any one of the modules/units/subunits may be split into a plurality of modules/units/subunits. Alternatively, at least part of the functionality of one or more of these modules/units/sub-units may be combined with at least part of the functionality 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 may be implemented at least partially 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 may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging a circuit, or in any one of three implementations of software, hardware, and firmware, or in any 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 that, when executed, may perform corresponding functions.

FIG. 12 schematically shows a block diagram of an electronic device according to an embodiment of the invention. The electronic device shown in fig. 12 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.

As shown in fig. 12, the electronic device 1200 includes a processor 1210, a computer-readable storage medium 1220. The electronic device 1200 may perform the program vulnerability detection method according to the embodiments of the present disclosure.

In particular, processor 1210 may include, for example, a general purpose microprocessor, an instruction set processor and/or related chip set and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), and/or the like. The processor 1210 may also include onboard memory for caching purposes. Processor 1210 may be a single processing unit or a plurality of processing units for performing different actions of a method flow according to embodiments of the present disclosure.

Computer-readable storage media 1220, for example, may be non-volatile computer-readable storage media, specific examples including, but not limited to: magnetic storage devices, such as magnetic tape or Hard Disk Drives (HDDs); optical storage devices, such as compact disks (CD-ROMs); a memory, such as a Random Access Memory (RAM) or a flash memory; and so on.

The computer-readable storage medium 1220 may include a computer program 1221, which computer program 1221 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 disclosure, or any variation thereof.

The computer program 1221 may be configured with, for example, computer program code comprising computer program modules. For example, in an example embodiment, code in computer program 1221 may include one or more program modules, including, for example, 1221A, modules 1221B, … …. It should be noted that the division and number of modules are not fixed, and those skilled in the art may use suitable program modules or program module combinations according to actual situations, and when the program modules 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.

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 computer program modules described with reference to fig. 12, which, when executed by the processor 1210, may implement the respective operations described above.

The present disclosure also provides a computer-readable storage medium, which may be contained in the apparatus/device/system described in the above embodiments; or may exist separately and not be assembled into the device/apparatus/system. The computer-readable storage medium carries one or more programs which, when executed, implement the program vulnerability detection method according to the embodiments of the present disclosure.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Those skilled in the art will appreciate that various combinations and/or combinations of features recited in the various embodiments and/or claims of the present disclosure can be made, even if such combinations or combinations are not expressly recited in the present disclosure. In particular, various combinations and/or combinations of the features recited in the various embodiments and/or claims of the present disclosure may be made without departing from the spirit or teaching of the present disclosure. All such combinations and/or associations are within the scope of the present disclosure.

The embodiments of the present disclosure have been described above. However, these examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although the embodiments are described separately above, this does not mean that the measures in the embodiments cannot be used in advantageous combination. The scope of the disclosure is defined by the appended claims and equivalents thereof. Various alternatives and modifications can be devised by those skilled in the art without departing from the scope of the present disclosure, and such alternatives and modifications are intended to be within the scope of the present disclosure.

Claims (14)

1. A program vulnerability detection method includes:

acquiring a program source code, extracting an 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-established vulnerability mode library, and collecting vulnerability path constraints corresponding to preset target defects;

after SMT standard conversion is carried out on the vulnerability path constraints, an SMT solver is used for solving the vulnerability path constraints, and whether the vulnerability path can be reached is judged;

if so, detecting whether a security vulnerability exists in a reachable path in the vulnerability path; otherwise, filtering an unreachable path in the vulnerability paths.

2. The program vulnerability detection method of claim 1, wherein the obtaining program source code, extracting intermediate code in the program source code, comprises:

the program source code is Java byte code, the intermediate code in the program source code is extracted by using a Soot frame, and the extracted intermediate code comprises at least one of intermediate codes in Baf, Jimple, Shimple or Grimp formats.

3. The program vulnerability detection method of claim 2, wherein the intermediate code is a Jimple format intermediate code, and the Jimple format intermediate code in the program source code is extracted by using a root framework, the method comprising:

variables in the program source code are all declared at the beginning of a Jimple;

converting constant data in the program source code into byte type data;

taking virtual invoke or static invoke as prefixes for method calls in the program source code;

and expressing the control flows in the program source codes by goto label jump statements.

4. The program vulnerability detection method of claim 3, wherein the generating a control flow graph according to the intermediate code comprises:

initializing a null vertex set V and a null 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 an empty vertex set V;

traversing each statement in the Jimple format intermediate code, judging whether each statement is the goto label jump statement, if so, adding a vertex which is a new vertex of the goto label jump statement and an incoming vertex which is a first new edge of a label corresponding to the new vertex in the empty edge set E; otherwise, adding a second new edge of which the vertex is a new vertex of the current statement and the input vertex is a new vertex of a next statement of the current statement in the empty edge set E.

5. The program vulnerability detection method of claim 1, wherein the vulnerability pattern library comprises at least one of the following vulnerability patterns:

jsp Trojan, Sql injection, Servlet thread insecure or server side request forgery.

6. The program vulnerability detection method of claim 5, wherein traversing each node in the control flow graph according to a pre-created vulnerability pattern library comprises:

and performing node traversal by adopting a depth-first traversal algorithm, wherein the starting point of a traversal path is a starting node, the end point of the traversal path is a node matched with any vulnerability pattern in the vulnerability pattern library, and all assignment statements and jump conditions on the traversal path are synchronously recorded.

7. The program vulnerability detection method of claim 1, wherein the SMT standard transformation of the vulnerability path constraints comprises:

and converting the vulnerability path constraint into an SMI-LIB standard form by adopting a infix conditional prefix-to-prefix conditional algorithm or a prefix expression bracket generation algorithm.

8. The program bug detection method of claim 7, wherein the SMT solver is theorem solver Z3, and the step of SMT normalizing the bug path constraints further comprises:

and adding an SMI-LIB standard tail part to the vulnerability path constraint after the SMT standardization conversion to obtain a vulnerability path legal constraint set.

9. A program vulnerability detection apparatus, comprising:

the characteristic extraction module is used for acquiring a program source code, extracting an intermediate code in the program source code and generating a control flow graph according to the intermediate code;

the node traversing module is used for traversing each node in the control flow graph according to a pre-established vulnerability mode library and collecting vulnerability path constraints corresponding to preset target defects;

the SMT solving module is used for solving the vulnerability path constraint by using an SMT solver after the SMT standard conversion is carried out on the vulnerability path constraint, and judging whether the vulnerability path can be reached or not; and

the vulnerability detection module is used for detecting whether a security vulnerability exists in the reachable path in the vulnerability path when the vulnerability path is reachable; otherwise, filtering an unreachable path in the vulnerability paths.

10. The program vulnerability detection apparatus of claim 1, wherein the feature extraction module further comprises:

the intermediate code extracting unit is used for extracting an intermediate code in the program source code by using a Soot frame, wherein the intermediate code is a Jimple format intermediate code;

the control flow graph generating unit is used for initializing a null vertex set V and a null 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 an empty vertex set V; traversing each statement in the Jimple format intermediate code, judging whether each statement is a goto label jump statement, if so, adding a vertex which is a new vertex of the goto label jump statement and an incoming vertex which is a first new edge of a label corresponding to the new vertex in the empty edge set E; otherwise, adding a second new edge of which the vertex is a new vertex of the current statement and the input vertex is a new vertex of a next statement of the current statement in the empty edge set E.

11. The program vulnerability detection apparatus of claim 1, wherein the node traversal module further comprises:

the pattern matching unit is used for traversing nodes by adopting a depth-first traversal algorithm, wherein the starting point of a traversal path is a starting node, and the end point of the traversal path is a node matched with any vulnerability pattern in the vulnerability pattern library;

and the synchronous recording unit is used for synchronously recording all assignment statements and jump conditions on the traversal path.

12. The program vulnerability detection apparatus of claim 1, wherein the SMT solution module further comprises:

the path constraint conversion unit is used for converting the vulnerability path constraint into an SMI-LIB standard form by adopting a infix conditional prefix conversion conditional algorithm or a prefix expression bracket generation algorithm;

and the standard tail adding unit is used for adding an SMI-LIB standard tail to the vulnerability path constraint in the SMI-LIB standard form to obtain a vulnerability path legal constraint set.

13. An electronic device, comprising:

one or more processors;

a memory for storing one or more programs,

wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of any of claims 1-8.

14. A computer-readable storage medium storing computer-executable instructions for implementing the method of any one of claims 1 to 8 when executed.

Images