KR20070023873A - Vulnerability rule based system for software development - Google Patents

Abstract

A vulnerability rule based system for developing software is provided to reduce expense with prevention of security accidents by safely developing the software in a source level and shorten software development time by detecting the vulnerability through the system without making a developer develop the software in consideration of each vulnerability. A software structure analyzing module analyzes a structure of the software to obtain correct contents for a vulnerability function before a function related to the vulnerability is searched. A vulnerability detecting module searches the vulnerability of the software by using the generated software structure and a vulnerability rule. An alert module displays the contents for the vulnerability detected by the vulnerability detecting module to a screen. A rule generating module generates and stores the vulnerability rule to correctly discriminate the vulnerability not simple pattern matching of the vulnerability function. The rule generating module applies a rule generating module according to diverse vulnerability.

Description

Vulnerability rule based system for software development {VULNERABILITY RULE BASED SYSTEM FOR SOFTWARE DEVELOPMENT}

1 is an overall configuration diagram of a vulnerability rule-based system for applying the present invention

2 is a diagram illustrating a software structure analysis procedure according to the present invention.

3 is a diagram showing a vulnerability function state transition diagram proposed in the present invention

As many programs are developed and used due to the development of the Internet and computers, many security problems may occur due to the vulnerability of the software. Therefore, it is an object of the present invention to develop a more secure software when developing programs at the same time in both civil and military, to prevent security incidents in advance.

The present invention relates to a system for generating vulnerability rules and detecting software vulnerabilities based on them in order to develop secure software.

Here, the conventional concept for achieving the present invention will be described.

The Buffer Overflow Vulnerability has been a huge issue since Aleph One's “Smashing the Stack for Fun and Profit” in Phrack magazine 49, 1997, when he introduced the detailed principles and methods of buffer overflow. An attack method has been developed that exploits buffer overflow vulnerabilities. Attacks using buffer overflow vulnerabilities are done by deliberately overflowing local array variables in the stack region and overwriting the return addresses located nearby. That is, it overflows the buffer on the stack and replaces the return address or base pointer value stored in the same frame. At this time, the malicious code is included in the string inputted into the array (buffer), and the stack area where the return address is located is changed to the address (buffer address) where the malicious code is located. Try to construct a large string. At this time, the address and size of the buffer must be predictable. This can be obtained by trial and error attempting on the address and the size of the buffers. That is, a buffer overflow occurs by putting more data into the buffer than the specified amount. The following code is a simple buffer overflow example. The data that will be used to overflow the buffer is usually called egg.

void function (char * str) {

     char buffer [16];

     strcpy (buffer, str);

}

void main () {

     char large_string [256];

     int i;

     for (i = 0; i <255; I ++)

        large_string [i] = 'A';

     function (large_string);

}

The code above is an example of a function that exhibits a buffer overflow coding error in extreme cases. This program uses strcpy () instead of strncpy () to copy the supplied string without boundary checking. More specifically, first put 255 'A's in str. Then copy str into buffer. The buffer is allocated 16 bytes. Therefore, only 16 of the 255 'A's are copied into the buffer. The rest cannot enter the buffer, so it enters the SFP area. Since SFP is 4 bytes, 235 remain in the SFP area. Then enter the RET area. That is, the RET is 4 bytes, and this area is also overwritten and the RET value is changed.

Compiling and running this program will result in segment errors. The following figure shows the stack when a function is called.

(Figure 1) Stack of function calls in example code

Segment errors in this program occur because strcpy () copies * str (large_string []) until a null character appears in buffer []. buffer [] is much smaller than * str. buffer [] is 16 bytes long and you want to put 256 bytes in it. This means that an entire 250 byte is overwritten after a buffer on the stack. This includes SFP, RET, and even * str. And I filled the large_string with 'A'. The hex value of 'A' is 0x41. This means that the return address is now 0x41414141. This is outside the process address space. This is dlb when the function returns and attempts to read the next command from that address. So buffer overflows allow you to change the return address of a function. This allows you to change the execution flow of your program. The following figure illustrates a buffer overflow attack.

(Figure 2) Buffer Overflow Attack

The present invention has been made to solve the problem that a security accident occurred by developing the conventional insecure program, and to develop a secure software at the source code level, before searching for a function related to a vulnerability in this system. A software structure analysis module for analyzing the structure of the software to obtain a content about a more accurate vulnerability function; A vulnerability detection module for searching for a vulnerability of software using the generated software structure and vulnerability rule; An Alert module, which plays a role of showing contents of a vulnerability determined in the vulnerability detection module on a screen; A rule generation module that is responsible for generating and storing vulnerability rules for more accurate vulnerability determination instead of simply pattern matching of a weak function to detect a vulnerability of software; It includes the purpose of creating software vulnerabilities into rules, and then uses the rules to detect software vulnerabilities.

Since most of the security vulnerabilities are due to software vulnerabilities and most of the software vulnerabilities are related to buffer overflow vulnerabilities, the present invention relates to a vulnerability rule-based system for making secure software which is the most fundamental method for preventing buffer overflow.

Hereinafter, exemplary embodiments of a rule-based software vulnerability detection system according to the present invention will be described in detail with reference to the accompanying drawings.

1 is an overall configuration diagram of a vulnerability rule-based system for applying the present invention. The system consists of four modules: software analysis module, vulnerability detection module, alert module, rule generation module, vulnerability rule database, and software structure database. Vulnerability rule database is a place that creates and stores software vulnerabilities as rules, and software structure database is a structure that analyzes and stores the structure of software to be inspected into variables and functions. 1 is a system structure proposed in the present invention. Detailed description of each module is as follows.

The software structure analysis module analyzes the structure of the software to obtain more accurate information about the vulnerability function before searching for the function related to the vulnerability. The software structure analysis sequence is as follows.

end. Step 1. After entering the program source, separate the function and the variable through the parser.

I. Step 2. Function processing extracts information about the function and stores it.

  -In the function processing section, information about a function is stored in the database in the following configuration.

   1) Module name: Module name to which current function belongs

   2) Function Name: Function Name

   3) Step: Shows the inclusion of functions as functions within them can be used

   4) Vulnerability: Check whether it is a vulnerable function through the vulnerability rule database. Until this point, no vulnerability is confirmed.

   5) Parameter: It stores the variables of the parameter used in the function.

All. Step 3. Variable processing extracts and stores information about variables.

   -In the variable processing section, information about variables is stored in the database with the following configuration.

   1) Variable Name: Name of Variable

   2) Variable type: save the data type of the variable

   3) Locality: Check whether it is global or local

   4) Local name: save the name of the area to which the function belongs

   5) Step: Elements to distinguish this name because they may have the same local name

   6) Variable value: input the value saved in the variable

la. Step 4. Repeat steps 1, 2 and 3 until the end of the program.

Figure 2 shows a procedure for analyzing the structure of the software, which illustrates the above procedure.

The vulnerability detection module detects software vulnerabilities by using the generated software structure and vulnerability rules in the vulnerability detection module. The functions related to the vulnerabilities and the variables used by the functions in the function part of the software structure table generated by the software structure analysis. Extract the information on and configure the vulnerability detection table as follows.

   Vulnerability Detection Table

   ① Function Name: Vulnerable Function Name

   ② Variable name: Variable used in vulnerable function

   ③ Variable value: the value stored in the variable

   ④ Vulnerability: After determining whether the vulnerability is stored

   ⑤ Vulnerability cause: Store the cause of vulnerability (determination of vulnerability according to variable size, rule rule)

Then, based on the contents of the vulnerability detection table and the vulnerability rule, the actual vulnerability of the function is determined and transmitted to the Alert module.

The Alert module plays the role of showing on the screen the vulnerability identified in the vulnerability detection module. The output to the screen is as follows.

   1) Vulnerable Function Name: Name of the vulnerable function

   2) Name of variable used: Name of the variable used

   3) Reason for vulnerability: Describe the cause of the vulnerability

   4) Vulnerability Resolution: Providing a way to solve the vulnerability

The rule generation module is responsible for creating and storing vulnerability rules for more accurate vulnerability determination, not just pattern matching of vulnerable functions to detect software vulnerabilities. In general, in order to solve a security problem using a weak function, it is desirable to write a program with an appropriate substitution function. However, this transition to alternative functions is not well done due to the programmer's personality and lack of security awareness. Therefore, in order to solve this problem, a research has been conducted to find a weak function by pattern matching and replace it with an alternative function. In other words, in the case of strcpy, the vulnerability function, whether the vulnerability is determined depends on the value of the variable used. In strcpy (A, B), buffer overflow may occur if the size of variable A is larger than variable B, but if the size of variable A is smaller than B, buffer overflow does not occur. Therefore, in this paper, we make a rule to determine the vulnerability according to the value of each variable, and based on this, we can check whether the vulnerability is more accurate.

Finally, the vulnerability used in the vulnerability rule module targets a function that causes a buffer overflow. The vulnerability for each function is defined as a set of rule R as follows.

R = {A, N, F, E}

A: set of vulnerability states

F: vulnerability function

N: transition function to the next state

-E: last state of vulnerability

In addition, the set of functions existing in the program is defined as SF, and when SF ∋ a, F ∋ a determines whether there is a vulnerability, and A = {N0, N1, N2,... , Nn} and E = {N2,... , Nn}, the state becomes N1 by the transition function N (N0, a) = N1. This means that when the vulnerability function a is input from the initial state N0, it transitions to the next state, N1.The state change of the vulnerability function is defined as a rule, and the state is transferred according to the rule so that the final state is the last state of the vulnerable function. Check if it is the same as (E). If so, this function turns out to be a weak function. In other words, if V is a set of variables whose value and size are not determined among the variables used in software,

1) F ∋ v1

2) If V ∋ v1

N (N1, v1) = N2 is established. If E = N2, this function is determined to be a vulnerability function, and by defining each of these state changes as a rule, various future vulnerabilities can be added to the rule. Another state change is that when the entire set of variables is called VA,

1) VA ∋ v1, v2

2) F ∋ v1, v2

3) If strcpy (v1, v2) and size (v1)> size (v2)

The strcpy function is a vulnerability function because N (N1, v1, v2) = N2 is established and E = N2. Therefore, the above state change is represented as a figure 3.

According to the present invention, since the software can be developed in a secure form at the source level, cost can be reduced by preventing future security incidents in advance, and a secure program can be developed to increase reliability.

In other words, program developers can detect vulnerabilities through the system without having to consider software vulnerabilities in order to develop them. The cost of the problem can be reduced.

The configuration and operation as described above are not limited to the claims of the present invention as an embodiment, and various changes and modifications are possible within the scope of not changing the technical spirit of the present invention. It is obvious to one.

Vulnerability rule-based system according to the present invention having the above configuration and action, since the software can be developed in a secure form at the source level, it is possible to reduce costs by preventing future security incidents in advance, and secure programs Development can increase reliability, and program developers can detect vulnerabilities through the system without having to consider software vulnerabilities in order to reduce the software development time.

Claims (2)

In a vulnerability rule based system, A software structure analysis module that analyzes the structure of the software to obtain more accurate information about the vulnerability function before searching for the function related to the vulnerability; A vulnerability detection module for searching for a vulnerability of software using the generated software structure and vulnerability rule; An Alert module, which plays a role of showing contents of a vulnerability determined in the vulnerability detection module on a screen; A rule generation module that is responsible for generating and storing vulnerability rules for more accurate vulnerability determination instead of simply pattern matching of a weak function to detect a vulnerability of software; The method of claim 1, Rule generation module is a rule-based system that creates rules according to state changes and applies rule generation algorithms according to various vulnerabilities.

Images