KR20190055776A - Method and apparatus for identifying security vulnerability and cause point thereof of executable binaries - Google Patents

Abstract

Provided is an automated method for determining a vulnerability present in a binary and a point which is a cause of the vulnerability. According to an embodiment of the present invention, a method for analyzing a binary vulnerability comprises: a first execution step of recording an execution flow path inducing a crash with respect to a binary and a symbolic constraint of vulnerability related to a suspicious element on the execution flow path by performing a taint analysis through execution of the binary which is a target to be analyzed; and a second execution step of performing a second execution of a symbolic execution method with respect to the execution flow path of the binary, and when an instruction satisfying the symbolic constraint is found, determining that the vulnerability is present in the binary based on a comparison result between the found instruction and the suspicious element.

Description

FIELD OF THE INVENTION [0001] The present invention relates to a method and apparatus for identifying a vulnerability of a binary,

The present invention relates to a security vulnerability to a binary and a method and apparatus for identifying the cause of the vulnerability. More particularly, to an automated method of determining a vulnerability in an executable binary and a location that causes the vulnerability.

The software is distributed in the form of executable binary (hereinafter 'binary') which is the result of compilation. The binary is loaded into the memory at the storage device and the software is executed by fetching some instructions of the binary from the memory to the processor.

Meanwhile, a variety of methodologies for grasping a vulnerability existing in the binary through the analysis of the binary have been proposed. The vulnerability may include, for example, a buffer overflow, an integer overflow, a memory exception, a race condition, a malformed-input, a symbolic link ) And null pointers are known. Because of the vulnerability, some functions of the binary may be unauthorizedly modified for an improper purpose, and a security problem may be caused in the system in which the binary is executed. Therefore, a binary executed in a security critical system can be quickly and accurately identified something to do.

However, nowadays, depending on the expert's knowledge, we are looking for the vulnerabilities existing in binary and the cause of the vulnerability. Therefore, there is a risk that the vulnerability can not be found according to the personal capacity of the expert, and it is difficult to quickly find the location of the vulnerability and its cause.

Therefore, it is required to provide a technique for detecting the vulnerabilities existing in the binary and the parts causing the vulnerabilities in an automated manner.

Korean Patent No. 10-1530132

SUMMARY OF THE INVENTION The present invention provides a method and apparatus for identifying a vulnerability embedded in a binary through an automatic analysis of a binary itself rather than searching for a vulnerability through an attack on the binary will be.

Another technical problem to be solved by the present invention is not only to identify a vulnerability imposed on a binary but also to provide a method and apparatus for identifying a part causing the vulnerability in an automated manner.

The technical objects of the present invention are not limited to the technical matters mentioned above, and other technical subjects not mentioned can be clearly understood by those skilled in the art from the following description.

According to an aspect of the present invention, there is provided a method of analyzing a binary vulnerability according to an embodiment of the present invention, which comprises performing a taint analysis through execution of a binary to be analyzed, And a symbolic constraint of a vulnerability associated with a suspicious element on the execution flow path; and a second execution step of writing the execution flow path of the binary Wherein when the instruction satisfying the symbol constraint condition is found, the vulnerability exists in the binary based on a result of the comparison between the found instruction and the suspect element, And a second execution step of determining that the second execution step is performed.

In one embodiment, the secondary execution step comprises the step of, when an instruction satisfying the symbol constraint condition is found, if the found instruction is at the same location as the suspect element, determining that the vulnerability exists in the binary .

In one embodiment, the secondary execution step includes: when an instruction satisfying the symbol constraint condition is found, if the found instruction is an instruction executed after the execution of the operand of the suspected element, the vulnerability exists in the binary .

In one embodiment, the secondary execution step includes performing the secondary execution only on the execution flow path of the binary.

In one embodiment, the primary execution step includes recording the tentuated element using information output as a result of the tent analysis, wherein the tentuated element comprises a tentative operand, a tentative memory address, And a suspicious element determination step of determining at least a part of the tentuated elements as a suspected element. At this time, the suspected element determining step may include a step of converting the binary into a pseudo code, and a step of, among the parts corresponding to the tentative element among the converted binary codes, Determining that the tentative element of the portion matched with the previously stored suspected operand pattern is a suspected element, or determining that the tentative element of the portion of the tentuated element that matches the previously stored suspected operand pattern is a suspected element Or determining that the instruction of the tentative element of the portion matched with the previously stored suspicious instruction pattern among the tentuated elements is a suspicious element.

In one embodiment, the primary execution step includes the steps of: performing the first-order execution using an execution parameter for executing the binary; and executing the first-time execution using the execution parameter, And setting it. In this case, the step of setting the tessellation source may include a step of, when the " main " does not exist in the debug symbol of the binary, As shown in FIG.

In one embodiment, the binary vulnerability analysis method may further include a step of, when the crash inducing value is not changed according to the tent record according to the tent analysis of the crash inducing value, which is an operand value when forced termination occurs according to the occurrence of the crash, And determining a location of a suspicious element closest to the forcible termination point on the execution flow path as a cause location of the vulnerability.

In one embodiment, the locating step further includes a step of determining a type of a cause location of the vulnerability as a first type that is a change point of the crash inducing value closest to the forced end point and a first type that is a position of a suspicious element closest to the forced end point And outputting the first and second types separately.

According to another aspect of the present invention, there is provided a method for analyzing a binary vulnerability, comprising: performing a taint analysis through execution of a binary to be analyzed; ) Of a crash inducing value that is an operand value at the time of forced termination according to the occurrence of the crash; and a step of writing a suspicious element on the execution flow path, And determining a location of a suspected element closest to the forcible end point on the execution flow path as a crash cause location when the crash inducing value does not change according to the tent record according to the analysis.

According to another aspect of the present invention, there is provided an electronic device including a processor, at least one instruction executed in the processor, and a memory storing one or more analysis target binaries. In this case, the one or more instructions may include a first instruction to execute the analysis target binary by inserting a code that grasps the execution status into the analysis target binary, a taint analysis through a first execution of the analysis target binary A second instruction for outputting information about an execution flow path that causes a crash for the binary; a second instruction for determining a suspicious element on the execution flow path and generating a symbol constraint condition of the vulnerability associated with the suspected element; And a fourth instruction for performing a second execution of the symbol execution method with respect to the execution flow path of the binary and notifying the third instruction when an instruction satisfying the symbol constraint condition is detected have. At this time, the third instruction is notified of the fourth instruction, and when the operand satisfying the symbol constraint condition is found, the vulnerability exists in the binary based on the result of the comparison of the found operand and the suspected element .

In one embodiment, the one or more instructions may include a step of, when the crash inducing value is not changed according to a tent record according to the tent analysis of a crash inducing value, which is an operand value when forced termination occurs according to the occurrence of the crash, And a fifth instruction for determining a location of a suspicious element closest to the forcible termination point on the execution flow path as a cause location of the vulnerability.

1 is a block diagram illustrating a binary vulnerability analysis system according to an exemplary embodiment of the present invention.
2 is a block diagram of a binary vulnerability analysis apparatus according to another embodiment of the present invention.
3 is a flowchart of a method for analyzing a binary vulnerability according to another embodiment of the present invention.
4 is a flowchart for explaining the first execution related operation of FIG. 3 in detail.
FIG. 5 is a flowchart for explaining some operations of FIG. 4 in detail.
6 is a flowchart for explaining a part of the operation of FIG.
FIG. 7 is a flowchart for explaining the second execution related operation of FIG. 3 in detail.
FIG. 8 is a flowchart for explaining the operation related to the analysis of the location cause of the vulnerability of FIG. 3 in detail.
9 is a flowchart of a method for analyzing a binary vulnerability according to another embodiment of the present invention.
10 is a hardware block diagram of a binary vulnerability analysis apparatus according to another embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS The advantages and features of the present invention and the manner of achieving them will become apparent with reference to the embodiments described in detail below with reference to the accompanying drawings. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Is provided to fully convey the scope of the invention to those skilled in the art, and the invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

Unless defined otherwise, all terms (including technical and scientific terms) used herein may be used in a sense commonly understood by one of ordinary skill in the art to which this invention belongs. Also, commonly used predefined terms are not ideally or excessively interpreted unless explicitly defined otherwise. The terminology used herein is for the purpose of illustrating embodiments and is not intended to be limiting of the present invention. In the present specification, the singular form includes plural forms unless otherwise specified in the specification.

Some embodiments of the present invention will now be described with reference to the drawings.

1 is a block diagram of a binary vulnerability analysis system according to an embodiment of the present invention. 1, the system according to the present embodiment may include a binary vulnerability analysis apparatus 100 acting as a server and one or more electronic devices 10a, 10b, 10c, 20 serving as clients. Note that the client may be a user terminal 10a, 10b, or 10c of a smart phone, a tablet, a notebook PC, or the like, but may be a server device 20 providing another service.

The binary vulnerability analysis apparatus 100 and one or more electronic devices 10a, 10b, 10c, 20 serving as clients may be electronic devices, for example computing devices having a computing processor.

In the system according to the present embodiment, the client performs an operation of providing the server 100 with a binary to be analyzed. The client can receive the analysis result from the server 100. The server 100 may analyze the provided binary in an automated manner to identify the vulnerability imposed on the binary. In one embodiment, the server 100 may identify the location that is causing the identified vulnerability. Further, in one embodiment, the server 100 may identify the cause location that causes a crash of the provided binary.

It is noted that the server 100 according to the present embodiment may collect the analysis target binaries by itself, rather than being provided with the binary by the client.

The server 100 may provide analysis results of the binaries to the clients 10a, 10b, 10c, and 20, or may manage the binaries by themselves.

Hereinafter, the configuration and operation of the binary vulnerability analysis apparatus 100 according to another embodiment of the present invention will be described with reference to FIG. 2, the binary vulnerability analysis apparatus 100 according to the present embodiment includes a binary executor 110, a symbol executor 120, a taint analyzer 130, a vulnerability classifier 140, a suspicious element DB 160, a vulnerability-causing localizer 150, and an interface 170. The interface 170 refers to a software or hardware module that is input to the binary vulnerability analysis apparatus 100 or performs an operation of mediating the output of the binary vulnerability analysis apparatus 100.

The binary executor 110, the symbol executor 120, the taint analyzer 130, the vulnerability classifier 140, the suspicious element DB 160 and the vulnerability locator 150 are physically separated dedicated computing devices Or at least a portion thereof may be configured together in one computing device in the form of a software module or hardware module part.

The binary executor 110 includes a binary execution module 111 for receiving a binary to be analyzed and executing the provided binary file and a binary status identification code insertion module 112 for instrumenting a code for identifying binary status information in the binary code ).

The binary execution module 111 executes the provided binary in accordance with the environment. The binary execution module 111 can execute the provided binary using execution parameters provided with the provided binary. The execution parameter is data which has been confirmed to cause a crash, and which is input to the binary internal logic at the time of execution of the binary.

The binary status identification code inserting module 112 provides 'binary code instrumentation' for binary control and information acquisition. The code inserted in the binary serves to output an internal state according to the execution of the provided binary.

The taint analyzer 130 determines whether the other factors are influenced by an element and analyzes the cause and influence of the problem using a case where the taint is influenced by a suspicious element . A variety of known techniques can be employed as a method of Tain analysis. In connection with the Taints analysis, various known documents such as "http://valgrind.org/docs/newsome2005.pdf" and "https://en.wikipedia.org/wiki/Taint_checking" can be referred to.

The taint analyzer 130 includes a taint engine 131 as a main logic for performing a taint analysis and a taint optimizer 131 for applying a method adapted to a pattern that is not detected by a conventional taint method and an optimizer 132. In the existing taint engine, it was judged that the contamination occurred only when the source of the assembly code (hereinafter referred to as the tent source) and the destination were connected. The Taint optimizer 132 performs logic to apply a conformance scheme to treat contaminated elements as conditionals and also to treat contaminated elements as a conditional statement. For a detailed description of the adaptation scheme, see DTA ++: dynamic taint analysis with targeted control-flow propagation. The taint source may be a portion for loading execution parameters of the analysis target binary. The method of setting the tent source will be described later.

The vulnerability classifier 140 determines the expected vulnerability of the analysis target binary. The vulnerability classifier 140 may include a suspicious element checker 141, a symbol constraint generator 142, and a vulnerability determination module 143.

The vulnerability classifier 140 receives the taint analysis result of the analysis target binary from the taint analyzer 130, reanalyzes the provided taint analysis result, and identifies the vulnerability of the analysis target binary using the reanalysis result And provides the set conditions to the symbol execution unit 120. The symbol execution unit 120 sets the conditions for the second execution. That is, the second execution is performed mainly by the symbol executor 120.

Since each element 110, 120, 130, 140, 150, 160, 170 shown in FIG. 2 operates in cooperation with each other when actually executed, no. In particular, the vulnerability classifier 140 performs a similar role as a kind of service daemon.

The suspicious element checking module 141 judges whether or not the element (including the operand, the memory address, and the register) tied to the previously known vulnerability from the settable source is set using the load position of the execution parameter causing the crash do. Concretely, the suspicious element identifying module 141 determines whether the element to be touched based on at least one of the presence or absence of an operable operand, an operand pattern, an instruction, and a pseudo code pattern is a suspicious element . The numeric code is parsed when the assembly language of the analyzed binary can be converted to a numeric code. The suspicious element confirming module 141 can obtain information on the previously known vulnerabilities from the suspicious element DB 160. [

The symbol constraint generator 142 sets a symbolic constraint that can identify a vulnerability corresponding to a suspicious element determined by the suspicious element determination module 141 and provides the symbol constraint to the symbol executor 120. The symbol constraint condition is to give a conditional expression to an execution flow path to be executed for symbolic execution.

The symbol execution unit 120 performs symbol execution on the analysis target binary. Symbol execution refers to executing a binary value by replacing it with a symbol rather than a concrete value. This is similar to developing a formula using unknowns in formulas. Symbol execution engine 121 replaces values by symbol in the binary execution process. Therefore, the branch condition according to the preference in the conditional statement included in the analyzed binary is grasped. SOLVER 122 obtains the value of a symbol according to a particular execution flow path.

Unless it is a simple binary, symbol starter 120 requires significant computing resources to obtain the value of that symbol for all possible execution flow paths of the binary. The binary vulnerability analysis apparatus 100 of this embodiment does not need to check all possible execution flow paths of the analysis target binary. All you need to do is check the execution flow path according to the execution parameter that causes the crash. This execution flow path is indicated by the timestamp of the timestamp analyzer 130. Therefore, the symbol executor 120 performs symbol execution only for the execution flow path indicated by the text record, and checks whether an instruction satisfying the symbol constraint condition provided by the vulnerability classifier 140 is found in the symbol execution process . If an instruction satisfying the symbol constraint is found, the symbol executor 120 notifies the vulnerability classifier 140 of the instruction. The vulnerability determination module 143 of the vulnerability classifier 140 receives the notification from the preference executor 120 and determines whether or not the vulnerability exists in the analysis target binary.

Hereinafter, the sequential process of determining the vulnerability will be described in detail.

The method according to claim 1, wherein, when an execution parameter for causing a crash to be analyzed is inputted to the analysis target binary, it can be confirmed through execution of the first execution flow path that the first execution flow path exists, Is confirmed by the element confirmation module 141. [ The suspicious element confirming module 141 refers to the known vulnerability related information of the suspicious element DB 160. [

The vulnerability corresponding to the first suspect element is also stored in the suspect element DB 160. Assuming that the vulnerability of the first suspect element is a buffer overflow, the symbol constraint generator 142 generates a symbol constraint that causes a buffer overflow in the first execution flow path.

Thereafter, the symbol execution unit 120 executes the symbol execution according to the first execution flow path, and notifies the vulnerability determination module 143 of the operand whose symbol constraint condition is satisfied.

The fact that an instruction satisfying a symbol constraint that causes a buffer overflow is found means that there is a possibility that a buffer overflow vulnerability exists in the analysis target binary. The vulnerability determination module 143 finally determines whether a buffer overflow vulnerability exists in the analysis target binary through comparison between the instruction satisfying the symbol constraint condition and the first suspect element.

For example, when the instruction satisfying the symbol constraint condition and the first suspect element are at the same position, the vulnerability determination module 143 determines whether or not a vulnerability of the buffer overflow exists in the analysis target binary can do. In addition, for example, if the instruction satisfying the symbol constraint condition is one after the first suspect element is executed, the vulnerability determination module 143 determines whether or not a vulnerability of the buffer overflow exists in the analysis target binary A final determination can be made.

The location detector 150 detects the cause of the vulnerability. When the location analyzer 150 analyzes the taint by the taint analyzer 130 and terminates the execution of the symbol by the symbol executor 120, the location detector 150 identifies the location of the vulnerability.

The vulnerability classifier 140 may output information on the vulnerability determined to be included in the analysis target binary through the interface 170. [

For example, the vulnerability locator 150 may determine a tenned operand associated with a location where a crash occurred and determine whether the value of the tenned operand is greater than the value that caused the crash A value of an operand, a register, or the like at the time of the forced termination due to the occurrence) as the location of the vulnerability.

In addition, for example, when the value causing the crash is not grasped or a change in the value causing the crash is not captured, the location locator 150 of the vulnerability causes the occurrence of the crash The location of the suspect element (identified by the suspect element identification module 141) closest to the forced termination position on the execution flow path may be identified as the cause of the vulnerability. The vulnerability-causing location detector 150 can output the detected result, that is, the location-related information that is the cause of the vulnerability through the interface 170. [

Next, a method of analyzing a binary vulnerability according to another embodiment of the present invention will be described with reference to FIGS. 3 to 8. FIG. The binary vulnerability analysis method according to this embodiment can be performed by an electronic device. The electronic device may be, for example, a computing device. The computing device may be, for example, the binary vulnerability analysis apparatus described with reference to FIGS. It should be noted that at least a part of the operation of the binary vulnerability analysis apparatus described with reference to FIGS. 1 and 2 may be included in the binary vulnerability analysis method. Therefore, the operation of the binary vulnerability analysis apparatus described with reference to FIGS. 1 and 2 can be included in the binary vulnerability analysis method even if there is no separate disclosure in the description of the binary vulnerability analysis method described below. Further, in the following description of the method, when there is no description of the subject of operation, the subject may be interpreted as the binary vulnerability analysis apparatus.

First, overall operation according to the present embodiment will be outlined with reference to FIG.

In step S100, the binary to be analyzed is first executed. At this time, as an execution parameter for the binary, an execution parameter causing a crash to the binary is inputted. At this time, a tent record, which is the result of the tent analysis using the execution parameter as a tent source, and a suspected element that is determined to exist on the execution flow path of the execution are output. Also, a symbol constraint condition for a vulnerability corresponding to the suspected element is output. The primary execution may be performed by the binary executor 110, the taint analyzer 130 and the vulnerability classifier 140 of FIG. This operation will be described in detail later with reference to FIG. 4 to FIG.

In step S200, the binary is executed secondarily, and the execution is limited to the execution flow path of the primary execution using the tape record output in the primary execution. In addition, in the course of execution of the symbol, when an instruction satisfying the symbol constraint condition output from the primary execution is found, the binary is added to the binary based on the comparison result between the instruction and the suspect element output from the primary execution Finally, a determination is made as to whether there is a vulnerability in which an instruction satisfying the symbol constraint is found. The primary execution may be performed by the binary executor 110, the symbol executor 120 and the vulnerability classifier 140 of FIG. This operation will be described later in detail with reference to FIG.

In step S300, the cause location of the vulnerability is determined using at least one of the result of the primary execution and the result of the secondary execution. This operation will be described later in detail with reference to FIG.

Next, step S100 will be described in more detail with reference to FIG.

In step S101, the binary to be analyzed is executed using an execution parameter that causes a crash of the binary. At this time, a taint source is set to perform the taint analysis (S103). The process of the tent source being touched on another operand or the like in the execution of the binary is tracked, and the result will be recorded or output as a tent record. Hereinafter, the setting operation of the tread source will be described with reference to Fig.

In this embodiment, the setting of the taint source depends on whether or not the " main " symbol exists in the debug symbol of the binary to be analyzed. That is, if there is " main " in the debug symbol of the binary (S1030), the taint source searches for the location of the instruction (that is, (S1032).

That is, when "main" does not exist in the debug symbol of the binary (S1030), it is difficult to know in which part of the binary the execution parameter is to be called before the actual execution of the binary. Accordingly, in this case, in the execution process of the binary, the location of the instruction to first fetch the external value is set to the tread source (S1034). If an external value is first loaded, it is likely that the external value is the immediate execution parameter. Referring back to FIG.

In step S105, it is determined whether the operand contained in the executed instruction is tentatively executed from the previously executed operand, while executing the instructions of the binary one by one in order (S107). It is subject to analysis only when the executed operand is tied. Thus, the memory address of the tenned operand or register and its associated instruction is recorded (S109). As a result of this recording, a tent record from a tent source is generated as shown in Table 1 below.

In step S111, it is determined whether or not the instruction including the tenned operand is a suspect element. This process can be performed, for example, by the suspicious element identifying module 141. Hereinafter, the process for determining whether a suspect element is present will be described in detail with reference to FIG.

In step S1110, at least one of the suspicious instruction pattern, the suspected operand pattern, and the suspicious pseudo code pattern is loaded from the suspect element DB. The suspect element DB stores suspicious instruction patterns, suspect operand patterns, and suspiciousness code patterns previously stored for each vulnerability type.

In step S1111, it is confirmed whether or not the binary can be converted into a numerical code. If the conversion is possible, the binary is converted into a numerical code (S1112). Next, in step S1113, it is determined whether or not the portion corresponding to the instruction including the tenned operand coincides with the suspect degree code pattern. If it is determined that the portion matches the suspect degree code pattern, (S1114).

In step S1115, it is determined whether the portion corresponding to the tenninal operand matches the suspected operand pattern. If it is determined that the portion matches the suspected operand pattern, a portion matching the suspected operand pattern is recorded as a suspected element (S1116).

In step S1117, it is determined whether the instruction corresponding to the tenninal operand matches the suspicious instruction pattern. If it is determined that the instruction matches, the instruction corresponding to the tenninal operand is recorded as a suspect element (S1118). The suspect instruction pattern may be such that, for example, in instructions such as " mov ecx, A ", A exceeds a predefined limit. The ecx register is a register that is often used for index lookups, and entering an unusual large value into the index value will be a problematic instruction.

In step S1119, if there is a part to be inspected among the tainted elements, the suspicious element checking operation is terminated if all the tentuated elements have been inspected.

Returning back to FIG. If it is determined in step S111 that the instruction including the instruction including the tenned operand is a suspicious element, the suspect element is recorded, and the suspect element DB inquires a vulnerability related to the suspect element (S113) . A plurality of suspected elements can be identified for the entire binary, and the locations of suspected elements, suspected elements (i.e., memory addresses) and associated vulnerabilities are matched and recorded. Table 2 below is an example of a record of suspected elements.

Suspicious Factor Suspicious Element Location Related Vulnerabilities strcpy 0x400x02 Buffer Overflow Call malloc 0x400c5e Memory Exception

In step S115, the symbolic constraint of the recorded suspect element is retrieved and recorded.

In one embodiment, the symbol constraint may be a one-to-one correspondence with the associated vulnerability of the recorded suspect element. For example, if the related vulnerability of the recorded suspect element is a Null Pointer error, the symbol constraint is as follows.

pc> higher_boundary_binary | pc <higher_boundary_binary & last_memory == null

The symbol constraint means that the pc value points outside the binary executable area, and the last memory accessed is null.

In another embodiment, the symbol constraint may be generated in consideration of both the related vulnerability of the recorded suspect element and the execution flow path depending on the recorded suspect element and the location of the recorded suspect element.

In step S117, if there is no instruction to be executed for the binary, the data for the recorded suspect element and the symbol constraint condition is output.

Next, the secondary execution step of step S200 will be described in detail with reference to FIG.

The binary to be analyzed and the execution parameters are received in step S201, and the symbol constraint condition for each suspect element, which is output as a result of the first execution in step S203, is set in the symbol execution unit. That is, a plurality of symbol constraint conditions can be set to the symbol executor in parallel.

The instructions are executed one by one in step S205. As described above, in the symbol execution process, it is not necessary to check all possible execution flow paths of the analysis target binary. Therefore, it is possible to perform the symbol execution only for the execution flow path indicated by the tent record outputted as the result of the primary execution, and to confirm whether the instruction satisfying the set symbol constraint condition is found in the symbol execution process.

If an instruction satisfying one of the set symbol constraints is found in the execution of the symbol (S207), a vulnerability existing in the analysis target binary is determined based on the comparison result between the found instruction and the written suspect element (S207 ). In one embodiment, upon discovery of an instruction satisfying the symbol constraint, if the found operand is of the same location as the suspect element, it may be determined that the vulnerability exists in the binary. In another embodiment, if the found instruction is an operand executed after the suspect element is executed, it may be determined that the vulnerability exists in the binary.

In step S211, when there is no more instruction to be executed for the binary, information about the vulnerability determined to exist in the binary is output and the secondary execution process is terminated.

Next, referring to FIG. 8, the location identifying step causing the vulnerability will be described in detail.

In step S301, a value causing a crash in the forced termination position due to a crash in the primary execution process (that is, the memory address of the forcibly terminated instruction) is inquired. At this time, the recorded value can be used in the case of forced termination during the taint analysis.

In step S303, the tent records generated by the tent analysis are rearranged in the reverse order of execution. As a result, the crash trigger value will be placed at the front of the reordered taint record. This operation is not necessarily required but it is possible to confirm the change of the crush induced value conveniently in the inquiry process.

In step S305, the change of the crash inducing value is tracked. If the change of the crash inducing value is confirmed (S307), the cause of the vulnerability is set to the position where the crash inducing value is initially changed on the re-arranged taint recording (S309).

On the other hand, when the change of the crash inducing value is not confirmed or the crash inducing value can not be confirmed, the position of the cause of the vulnerability is the closest to the forced end position on the execution flow path according to the primary execution result That is, the most distant place in the reordered taint record) (S311). In this case, it is assumed that the crash is caused not by the specific value but by the action of the suspected element itself.

When the information about the cause of the vulnerability is output, the method of identifying the suspected cause (1: backward trace (according to step S309), 2: suspicious element location (according to step S311) Can be matched and output.

For example, if you find the location of the cause of an Integer Overflow vulnerability by backtracking a crash-induced value change, the following information may be output: The information below refers to [how to identify the cause of the suspect, the location of the vulnerability, and the type of vulnerability].

[1, 0x40012b, Integer Overflow]

Next, a method of analyzing a binary vulnerability according to another embodiment of the present invention will be described with reference to FIG. The binary vulnerability analysis method according to the present embodiment outputs data on the location of the cause of the crash. The method for analyzing binary vulnerability according to the present embodiment may include determining a cause of a crash only by performing a first execution for analyzing a taint and a taint recording according to the taint analysis.

In step S400, an execution flow path for performing a taint analysis through execution of a binary to be analyzed and causing a crash to the binary, and an execution flow path for causing a crash to the binary, Record the suspicious element. Note that the operation of this step can be partially applied to the method described with reference to Fig.

If the crash inducing value does not change in accordance with the tent record according to the tent analysis of the crash inducing value, which is an operand value at the time of forced termination according to the occurrence of the crash, at step S500, The position of the suspected element closest to the end point is determined as the cause of the crash. Note that the operation of this step can be partially applied to the method described with reference to Fig.

Next, the configuration and operation of the binary vulnerability analysis apparatus according to another embodiment of the present invention will be described with reference to FIG. 10, the vulnerability analysis apparatus 100 according to the present embodiment includes a processor 101 and a memory 102, and in some embodiments, a storage 103, a network interface 105, And a bus 104. [0028] One or more instructions loaded and stored in the memory 102 are executed through the processor 101. The binary vulnerability analysis apparatus 100 according to the present embodiment may perform the operations related to the binary vulnerability analysis apparatus described with reference to FIGS. 1 and 2 and the operation related to the binary vulnerability analysis method described with reference to FIGS. Can be performed.

The network interface 105 may receive the analysis target binary 130a provided from the external device via the network and store the received analysis target binary 130a in the storage 103. [

Wherein the one or more instructions include a binary execution instruction (110a) for inserting a code for identifying execution status into the analysis target binary and loading (130b) the analysis target binary (130a) A taint analysis instruction (130a) for performing a taint analysis through the execution flow path (130a) to output information about an execution flow path causing a crash for the binary, a suspicious element on the execution flow path A vulnerability class instruction 140a for generating a symbol constraint of a vulnerability associated with a suspect element, and a second execution of a symbol execution method for the execution flow path of the binary, and when an instruction satisfying the symbol constraint condition is detected And a symbol execution instruction 120a for notifying the third instruction .

In one embodiment, the vulnerability class instruction 140a uses the suspicious element DB 160 stored in the storage 103 to determine a suspect element on the execution flow path.

In one embodiment, the vulnerability class instruction 140a may be provided with a notification of the fourth instruction and, upon discovery of an instruction satisfying the symbol constraint condition, It can be determined that a vulnerability exists.

In one embodiment, when the crash inducing value is not changed when the at least one instruction follows a timestamp according to the timestamp analysis of a crash inducing value, which is an operand value when forced termination occurs according to the occurrence of the crash, And a location determination instruction 150a for determining a location of a suspicious element closest to the forcible termination point on the execution flow path as a cause location of the vulnerability.

The methods according to the embodiments of the present invention described so far can be performed by the execution of a computer program embodied in computer readable code. The computer program may be transmitted from a first computing device to a second computing device via a network, such as the Internet, and installed in the second computing device, thereby enabling it to be used in the second computing device. The first computing device and the second computing device all include a server device, a physical server belonging to a server pool for cloud services, and a fixed computing device such as a desktop PC.

The computer program may be stored in a recording medium such as a DVD-ROM, a flash memory device, or the like.

While the present invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, I can understand that. It is therefore to be understood that the above-described embodiments are illustrative in all aspects and not restrictive.

Claims (14)

A method performed by a computing device,
The execution flow path for causing a crash to the binary by performing a taint analysis through execution of a binary to be analyzed and a suspicious element on the execution flow path, a primary execution step of recording a symbolic constraint of a vulnerability associated with an element; And
Performing a second execution of a symbolic execution method on the execution flow path of the binary, when an instruction satisfying the symbol constraint condition is found, a result of comparison between the found instruction and the suspicious element A second execution step of determining that the vulnerability exists in the binary,
How to analyze binary vulnerability. The method according to claim 1,
Wherein the secondary execution step comprises:
Determining that the vulnerability exists in the binary if the found instruction is at the same location as the suspect element upon discovery of an instruction satisfying the symbol constraint;
How to analyze binary vulnerability. The method according to claim 1,
Wherein the secondary execution step comprises:
Determining that the vulnerability is present in the binary if the found operand is an operand executed after the suspect element instruction is executed upon discovery of an instruction satisfying the symbol constraint condition;
How to analyze binary vulnerability. The method according to claim 1,
Wherein the secondary execution step comprises:
Performing the secondary execution only on the execution flow path of the binary,
How to analyze binary vulnerability. The method according to claim 1,
Wherein the first execution step comprises:
Recording the tennted elements using information output as a result of the tenns analysis, the tennted elements including a tenned operand, a tennted memory address, and a tennted register; And
And a suspicious element determination step of determining at least a part of the tentiated elements as a suspected element,
The suspected element determining step includes:
Converting the binary into pseudo code; And
Judging a tentative element of a portion of the converted binary number code corresponding to the tentative element that matches the previously stored suspect tentative code pattern as a suspicious element;
How to analyze binary vulnerability. The method according to claim 1,
Wherein the first execution step comprises:
Recording the tennted elements using information output as a result of the tenns analysis, the tennted elements including a tenned operand, a tennted memory address, and a tennted register; And
And a suspicious element determination step of determining a part of the tentiated elements as a suspected element,
The suspected element determining step includes:
Determining a tentative element of a portion of the tentative element that matches a previously stored suspected operand pattern as a suspect element.
How to analyze binary vulnerability. The method according to claim 1,
Wherein the first execution step comprises:
Recording the tennted elements using information output as a result of the tenns analysis, the tennted elements including a tenned operand, a tennted memory address, and a tennted register; And
And a suspicious element determination step of determining a part of the tentiated elements as a suspected element,
The suspected element determining step includes:
Determining an instruction of a tentative element of a portion of the tentative element that matches a previously stored suspicious instruction pattern as a suspected element.
How to analyze binary vulnerability. The method according to claim 1,
Wherein the first execution step comprises:
Performing the first-order execution using an execution parameter for executing the binary; And
And setting a tent source for the tent analysis using the execution parameter,
Wherein setting the tent source comprises:
Setting a location to load the execution parameter in the first execution step as a tentative source when " main " does not exist in a debug symbol of the binary,
How to analyze binary vulnerability. The method according to claim 1,
When the crash inducing value does not change according to the tent record according to the tent analysis of the crash inducing value, which is an operand value when the forced termination occurs according to the occurrence of the crash, And a location determination step of determining a location of a nearby suspect element as a location of a cause of the vulnerability,
How to analyze binary vulnerability. 10. The method of claim 9,
Wherein the positioning step comprises:
Distinguishing a type of a cause location of the vulnerability from a first type that is a change point of the crash inducing value closest to the forced end point and a second type that is a position of a suspected element closest to the forced end point and outputs the type; Including,
How to analyze binary vulnerability. In combination with the computing device,
11. A method according to any one of claims 1 to 10,
Software stored on computer readable media. A method performed by a computing device,
The execution flow path for causing a crash to the binary by performing a taint analysis through execution of a binary to be analyzed and a suspicious element on the execution flow path, element; And
When the crash inducing value does not change according to the tent record according to the tent analysis of the crash inducing value, which is an operand value when the forced termination occurs according to the occurrence of the crash, Determining a location of a nearby suspect element as a location of a crash origin;
How to analyze binary vulnerability. A processor; And
A memory for storing one or more instructions executed on the processor and one or more analyzed binaries,
Wherein the at least one instruction comprises:
A first instruction for inserting a code for grasping an execution state into the analysis target binary and executing the analysis target binary;
A second instruction for performing a taint analysis through a first execution of a binary to be analyzed and outputting information about an execution flow path causing a crash to the binary;
A third instruction for determining a suspected element on the execution flow path and for generating a symbol constraint condition of the vulnerability associated with the suspected element; And
And a fourth instruction for performing a second execution of the symbol execution method on the execution flow path of the binary and notifying the third instruction when an operand satisfying the symbol constraint condition is found,
The third instruction is provided with the notification of the fourth instruction and when the instruction satisfying the symbol constraint condition is found, it is determined that the vulnerability exists in the binary based on a result of the comparison between the found instruction and the suspected element ,
Electronic device. 14. The method of claim 13,
Wherein the at least one instruction comprises:
When the crash inducing value does not change according to the tent record according to the tent analysis of the crash inducing value, which is an operand value when the forced termination occurs according to the occurrence of the crash, Further comprising a fifth instruction to determine a location of a nearby suspect element as a location of the vulnerability.
Electronic device.

Images