KR102117012B1 - System and Method for Supporting Secure Programming for PLC based on Coding Rule - Google Patents

Abstract

The present invention is to support secure programming for PLC based on coding rules that can enhance the security of the PLC program by statically analyzing binary files before the executable code is downloaded to the PLC when programming for the PLC. Regarding devices and methods, a function sanitizer that generates call graphs from executable code and detects functions that are not allowed in the coding rules manual or standard library functions that can adversely affect the PLC; disassemble the executable code After that, it detects the anomaly operation pattern for the pointer variable and uses the source code and symbol information to detect or set the memory value that can be a threat to security and safety. Pointer sanitizer; It includes a timer and a pointer sanitizer, and an executable code sanitizer is configured. The executable code sanitizer is statically analyzed before downloading the executable code from the integrated development environment (IDE) to the PLC, and the function By identifying standard library functions that can adversely affect the PLC detected by the sanitizer and functions that are not allowed in the coding rules manual, and setting or changing the memory values that may threaten the security and safety detected by the pointer sanitizer. To be removed.

Description

{System and Method for Supporting Secure Programming for PLC based on Coding Rule}

The present invention relates to programming for the PLC, specifically, a PLC based on a coding rule that enables the security of a PLC program to be enhanced by statically analyzing binary files before the machine code (machine code, executable code) is downloaded to the PLC. And a method and apparatus for supporting secure programming.

PLC (Programmable Logic Controller) is a computer-based single processor device used in a control process that requires high reliability with real-time requirements.

The PLC is a major part of the industrial automation system, and is typically applied to industrial control systems such as process control, supervisory control and data acquisition (SCADA) systems, and nuclear power plants.

According to the definitions described in the standard ICS3-1978, PLCs use "programmable memory to perform special functions such as logic, sequencing, timing, counting, and computation through digital or analog input / output modules. And electronic devices that perform digital operations to control various types of machines or processors.

As programmable PLCs offer more flexibility than traditional hard-wired controls, most of the control elements that implement the logic of industrial systems are being replaced by PLCs.

In industrial control systems, PLCs are connected to input / output devices (eg valves, switches, sensors) or other PLCs to monitor inputs and outputs according to the process.

With the recent development of IoT technology, PLC is widely used in applications such as motor control, pumping system, and system monitoring.

Recent PLC products, including the Siemens S7 series, can also be accessed remotely via an Internet connection. As PLC connected to the Internet plays an important role in critical infrastructures such as industrial control systems, it is gradually becoming a main target of cyber attacks.

Starting with Stuxnet, which stopped operating uranium centrifuges in Iran's nuclear facilities in 2010, Duqu, which aimed at collecting and leaking control system information in 2011, flames that damaged power control systems in Middle Eastern countries in 2012 ( Flame) and other malicious codes are typical examples.

In the case of Stuxnet, it was an attack on the PLC's integrated management tool that controls the nuclear power centrifuge, and through this, a malicious command was transmitted to the PLC.

As the operating system for PLC, embedded real-time operating system (RTOS) such as VxWorks, Microware OS-9, QNX Neutrino, Linux, Windows CE, uC / OS is used.

However, these PLC operating systems have vulnerabilities, and it is necessary to eliminate or mitigate these vulnerabilities.

Shutdown and malfunction of industrial facilities due to cyber attacks against PLCs in industrial control systems can have serious consequences that threaten public safety and the environment.

The techniques for preventing cyber attacks against PLCs of industrial control systems in the prior art will be described as follows.

First, there is Address sanitization technology.

The AddressSanitizer (ASan) framework is a framework that dynamically checks the vulnerability of programs by inserting and compiling the stub code that indicates the main memory area along with the source code written by the developer.

The core process of the ASan framework is to insert stub code that marks critical memory areas at the compiler level when compiling the source code.

The compiled program operates by detecting and blocking memory forgery / modulation through memory shadowing and redzone techniques at execution time. Through this technique, the cause of the attack is identified and the wrong access is blocked for major memory attacks such as use-after-free and use-after-return, as well as incorrect access to main areas of memory (heap, stack, global variables).

Since this technique does not manage all memory areas, there are limitations to vulnerabilities that occur outside the proposed memory area.

In addition, the memory area of the process is managed through the shadow memory and redzone techniques, so process management techniques such as ulimit or static library cannot be used, and more than 12.5% of memory is consumed compared to the existing program.

Because of these limitations, the ASan technique is not suitable in embedded environments that are oriented towards low-power or low-end systems.

And as another part of the prior art, there is a method of analyzing whether an embedded executable file complies with the coding standards.

Venkitaraman et al. Conducted a study to check whether the executable file of the embedded environment conformed to the coding rules at the assembly level. In this method, the embedded executable is disassembled and expressed as a function-based flow graph, and the written flow graph complies with the coding standard rules and hard-coded. Check if the pointer variable is present.

A hard coded pointer variable is a variable that allocates a fixed memory address in the source code and can access memory directly in the source code. Most low-performance embedded devices or uC / OS operating systems consist of a single address system. Pointer variables can cause security or security vulnerabilities such as pointer aliases.

According to the coding standard guide provided by PLC control processor developers, the use of such pointer variables should be avoided.

Since the method for checking the compliance with coding standards is reviewed for the coding standard rules, access to functions with security vulnerabilities is not considered.

Therefore, this method detects hard-coded pointer variables, but can be considered to focus on safety rather than security.

Another method of the prior art is uC / OS operating system defense technology.

Sikiligiri's research showed that a stack buffer overflow attack is possible in the uC / OS operating system, and suggests a system that can defend it.

The system is designed so that the attacker does not know the stack address by storing the function call stack in a separate area. Since the attacker cannot know the stack address, it effectively prevents attacks such as code injection.

However, to use this system, separate hardware support is needed to store the function call stack.

In addition, in the case of a system composed of a single address space such as a PLC, the memory area composed of a separate call stack is also accessible to an attacker, and it is necessary to block the function that can cause a buffer overflow.

Therefore, there is a need to develop a new technology to solve the problems of the related arts and to strengthen the security of commands or download programs that are transmitted to the PLC from the tools that manage them as well as the vulnerabilities existing in the PLC itself in the control system. Is becoming.

Republic of Korea Patent No. 10-2016-0082644 Republic of Korea Patent No. 10-1479516 Republic of Korea Patent No. 10-2018-0010053

The present invention is to solve the problems of the programming technology for the PLC of the prior art, before the machine code (machine code, executable code) is downloaded to the PLC, by statically analyzing the binary file to enhance the security of the PLC program The purpose is to provide a device and method for supporting secure programming for PLC based on one coding rule.

The present invention analyzes compiled machine code and source code, if necessary, after writing an application to operate the PLC, and can detect unnecessary use of standard library functions and use of hard-coded pointers in addition to the functions described in the manual to eliminate security-vulnerable bugs. The aim is to provide a device and method for supporting secure programming for PLC based on the coding rules.

The present invention is intended to support secure programming for PLC based on coding rules that enable program code developers to detect unintended vulnerable library functions and pointer operations by inspecting executable code to be directly downloaded to the PLC, thereby enhancing the security of the PLC. The purpose is to provide an apparatus and method.

The present invention provides safe programming for PLC based on coding rules that assemble binary code to detect whether an anomaly operation of a pointer variable is executed using execution code, and check an abnormal usage pattern of a pointer variable at an assembly level. The purpose is to provide a device and method for supporting.

In order to improve the validity and accuracy of the pointer sanitizer, the present invention is based on a coding rule for calculating a range of a stack of each task through source code and symbol information and detecting a pointer operation outside the address range assigned to each task. The aim is to provide a device and method for supporting secure programming.

Other objects of the present invention are not limited to those mentioned above, and other objects not mentioned will be clearly understood by those skilled in the art from the following description.

The apparatus for supporting safe programming for PLC based on the coding rule according to the present invention for achieving the above object is allowed in a standard library function or coding rule manual that can generate a call graph from execution code and adversely affect the PLC. A function sanitizer that detects non-functional functions; after disassembles the execution code, detects anomaly operation patterns on pointer variables, and uses source code and symbol information to pose a security and security threat. Pointer sanitizer to detect possible memory value setting or change; includes the function sanitizer and pointer sanitizer, and the executable code sanitizer is configured, and the executable code sanitizer is configured in an integrated development environment (IDE). Standard library functions and functions that are not allowed in the coding rules manual that can affect the PLC detected by the function sanitizer by statically analyzing the executable code before downloading to the PLC, the pointer sanitizer It is characterized by identifying and removing memory value settings or changes that can threaten the detected security and safety.

Here, the function sanitizer compares the function list of the task represented by the execution code developed by the program code developer with the signature DB (Database), and the function list of the task is extracted through the call graph generated from the execution code It is characterized by including the function name.

In addition, the signature DB is characterized by managing standard function names that are not allowed in the development manual or weak standard function names as signatures.

And the function list that can adversely affect the security and safety in the function sanitizer is composed of 'Buffer Overflow vulnerable function' and 'Memory vulnerability related function', and Buffer Overflow vulnerable function is ' trcat () ', trcpy ( ) ',' strncpy () ',' sprintf () ',' vsprintf () ',' gets () ',' fscanf () ',' scanf () ' and ' calloc () ) ',' free () ',' malloc () ',' realloc () ',' memcpy () ',' memset () ', and' memmove () ' .

In addition, the function sanitizer generates a call graph from the executable code, analyzes function names and call relationships between functions used by system and program code developers from the generated call graph, and is developed by program code developers. After comparing the function list of the task represented by one execution code with the signature DB (Database), after detecting the standard library functions that can adversely affect the PLC or functions that are not allowed in the coding rules manual, any position through the call graph It is not allowed in the standard library function or coding rules manual that the function sanitizer understands which function is used in the function, compares the result obtained by the function sanitizer with the source code, and can adversely affect the PLC by the program code developer. It is characterized by determining whether functions are included.

In addition, the pointer sanitizer performs anomaly operation pattern detection operation on the pointer variable targeting the execution code, and analyzes the source code when it is difficult to detect anomaly operation pattern targeting the execution code. It is characterized by extracting the information necessary for anomaly operation pattern detection, and detecting a command pattern that sets a specific value by hardcoding the address directly into a pointer variable.

In addition, the pointer sanitizer, the source code and symbol information, the range of each task stack represented by the execution code developed by the program code developer, the argument indicating the starting point of the task code (App_Task2), the start of the task stack Using the argument (App_TaskPostStk []), which is a pointer to the location, the location indicated by App_TaskPostStk [] checks the memory address through symbol information and uses the value of the argument (APP_CFG_TASK_STK_SIZE) to specify the size of the stack. It is characterized by improving the validity and accuracy by checking and calculating the range, and detecting pointer operation outside the address range assigned to each task.

In addition, the pointer sanitizer includes a pattern DB that manages a code pattern necessary to detect pointer variable operation, and analyzes the assembly usage pattern of the CPU of the target PLC to generate a signature to be maintained in the pattern DB. .

In addition, the pattern to be detected by the pointer sanitizer is composed of instructions for assigning a hardcoded address value to the pointer variable and instructions for changing the value of the address address indicated by the pointer variable.

Then, the pointer sanitizer performs assembly code analysis by disassembled the machine code to apply the pointer sanitizer targeting the machine code, and performs anomaly operation pattern detection operation on the pointer variable, It is characterized by identifying hard-coded memory address values using only assembly code or identifying hard-coded memory address values by analyzing the source code.

delete

The method for supporting secure programming for PLC based on the coding rule according to the present invention for achieving another object is statically analyzed before downloading the executable code from the integrated development environment (IDE) to the PLC, and function function Generating a call graph from the executable code by the function sanitizer in order to identify and remove standard library functions or functions that are not allowed in the coding rule manual, which may adversely affect the PLC detected by the timer; Analyzing function names and call relationships between functions used by system and program code developers from the generated call graph; comparing the function list of tasks represented by execution code developed by program code developers with signature DB (Database) Step; detecting standard library functions that can adversely affect the PLC or functions that are not allowed in the coding rules manual, and using the call graph to determine which function is used in which position and function sanitizer; function sanitizer It is characterized by performing; comparing the result identified in the above with the source code to determine whether a standard library function that can adversely affect the PLC by a program code developer or a function not allowed in a coding rule manual is included.

Here, the signature DB is characterized by managing a standard function that is not allowed in the development manual or a weak standard function name as a signature.

In addition, the function list that can adversely affect security and safety in the function sanitizer is composed of 'Buffer Overflow vulnerable function' and 'Memory vulnerability related function', and ' trcat () ', trcpy ( ) ',' strncpy () ',' sprintf () ',' vsprintf () ',' gets () ',' fscanf () ',' scanf () ' and ' calloc () ) ',' free () ',' malloc () ',' realloc () ',' memcpy () ',' memset () ', and' memmove () ' .

The method for supporting safe programming for PLC based on the coding rule according to the present invention for achieving another object is statically analyzed before downloading the executable code from the integrated development environment (IDE) to the PLC, and the pointer Pointer sanitizer is expressed as executable code developed by program code developers through source code and symbol information to identify and remove memory value settings or changes that could threaten security and safety detected by Taiger The location of App_TaskPostStk [] indicates the symbol information using the range of each task stack, the argument (App_Task2) as a pointer to the starting point of the task code, and the argument (App_TaskPostStk []) as a pointer to the starting position of the task stack. Checking the memory address through, and calculating by checking the stack range of the task using the value of the argument (APP_CFG_TASK_STK_SIZE) that specifies the size of the stack; check if there is a pointer variable in the source code of the task, and check the pointer variable It characterized in that it comprises a step of: checking whether the memory address is hard-coded; detecting an address value input to a pointer variable when it is out of a stack range of a corresponding task.

In addition, the pointer sanitizer performs anomaly operation pattern detection operation on the pointer variable targeting the execution code, and analyzes the source code when it is difficult to detect anomaly operation pattern targeting the execution code. It is characterized by extracting the information necessary for anomaly operation pattern detection, and detecting a command pattern that sets a specific value by hardcoding the address directly into a pointer variable.

In addition, the pointer sanitizer includes a pattern DB that manages a code pattern necessary to detect pointer variable operation, and analyzes the assembly usage pattern of the CPU of the applicable PLC to generate a signature to be maintained in the pattern DB. .

In addition, the pattern to be detected by the pointer sanitizer is composed of instructions for assigning a hardcoded address value to the pointer variable and instructions for changing the value of the address address indicated by the pointer variable.

Then, the pointer sanitizer performs assembly code analysis by assembling the machine code to apply the pointer sanitizer targeting the machine code, and when performing anomaly operation pattern detection operation on the pointer variable, It is characterized by identifying hard-coded memory address values using only assembly code or identifying hard-coded memory address values by analyzing the source code.

The apparatus and method for supporting secure programming for PLC based on the coding rule according to the present invention as described above has the following effects.

First, before the machine code (machine code, execution code) is downloaded to the PLC, the binary file is statically analyzed to enhance the security of the PLC program.

Second, after writing the application to operate the PLC, the compiled machine code and, if necessary, the source code are analyzed to detect unnecessary use of standard library functions and the use of hard-coded pointers in addition to the functions described in the manual, thereby eliminating vulnerable security bugs. .

Third, by inspecting the executable code to be downloaded directly to the PLC, it is possible to enhance the security of the PLC by detecting vulnerable library functions and pointer operations not intended by the program code developer.

Fourth, by assembling the binary code, it is possible to detect anomaly operation of the pointer variable by checking the abnormal usage pattern of the pointer variable at the assembly level.

Fifth, it is possible to improve the validity and accuracy of the pointer sanitizer by calculating the range of each task's stack through source code and symbol information, and detecting pointer operations outside the address range assigned to each task.

Sixth, it is possible to enhance the security of the PLC by detecting in advance even if the developer accidentally uses an inappropriate function and pointer operation, or when the IDE infected with the malicious code randomly adds a malicious library function.

1 is a configuration diagram of a device for supporting secure programming for a PLC based on a coding rule according to the present invention
2 is a flow chart showing a method for supporting secure programming for a PLC based on a coding rule according to the present invention
3 is a block diagram showing an example of uC / OS code including strcpy
4 is a block diagram showing an example of a code for performing a pointer operation
5 is a configuration diagram of a memory value modulation result through pointer variable manipulation
6 is a call graph of uC / OS task
Figure 7 is an assembly code configuration diagram for Figure 4
8 is a block diagram showing an example of a code pattern for a pointer sanitizer
9 is a block diagram showing an example of uC / OS code prototype for generating a task
10 is a block diagram showing an example of symbol information for an executable code

Hereinafter, a preferred embodiment of an apparatus and method for supporting secure programming for a PLC based on a coding rule according to the present invention will be described in detail as follows.

Features and advantages of an apparatus and method for supporting secure programming for a PLC based on a coding rule according to the present invention will become apparent through detailed description of each embodiment below.

1 is a configuration diagram of a device for supporting secure programming for a PLC based on a coding rule according to the present invention.

The present invention includes an 'executable code sanitizer' for improving the security of a PLC system.

The present invention can detect and remove vulnerable functions and erroneous memory references that may be included during the development of a PLC control program using an executable code sanitizer.

To this end, first, the list of vulnerable functions is managed by the vulnerability DB, and the memory address mapping process of the task is identified.

Next, before the executable program developed and compiled in the integrated development environment (IDE) is downloaded to the PLC, the function information and reference address information of the task are extracted by analyzing the execution program, and the extracted information is vulnerable DB and memory address space. Compares and detects and eliminates security vulnerabilities.

In one embodiment of the present invention, an execution code developed for a uC / OS based PLC is analyzed to design an 'Executable Code Sanitizer' that detects and filters malfunctions and vulnerabilities of the PLC in advance. Implement it.

Micrium's uC / OS is a small microkernel RTOS. uC / OS is a priority-based multitasking operating system for microprocessors, mainly written in the C programming language.

Currently, uC / OS is used as embedded operating system of PLC or industrial control system.

The execution code sanitizer constituting a device for supporting safe programming for PLC based on the coding rule according to the present invention is a function that is vulnerable by statically analyzing the executable code in the integrated development environment (IDE) before downloading it to the PLC B. Identifies the use of pointers so that they can be removed.

As shown in FIG. 1, the executable code sanitizer is composed of two modules: a function sanitizer 100 and a pointer sanitizer 200.

The function sanitizer 100 enhances security by detecting a function not allowed in a standard library function or a coding rule manual that generates a call graph from execution code and may adversely affect the PLC.

The pointer sanitizer 200 may disassemble the executable code, detect anomaly operation patterns for pointer variables, and use source code and symbol information to become a security and safety threat. Detect or set memory values.

The method for supporting secure programming for PLC based on the coding rule according to the present invention having such a configuration performs the following operations.

2 is a flow chart showing a method for supporting secure programming for a PLC based on a coding rule according to the present invention.

First, the function sanitizer 100 generates a call graph from executable code. (S201)

Then, from the generated call graph, function names and call relationships between functions used by system and program code developers are analyzed (S202).

Then, the function list of the task related to the actual operation developed by the program code developer is compared with the signature DB (Database) to examine stability. (S203)

Subsequently, after detecting the use of an unsafe function through the function sanitizer 100, the call graph is used to determine which function is used in which position and compares the result of the function sanitizer 100 with the source code. . (S204)

In addition, it is determined whether unnecessary functions are included due to mistakes or malicious actions of the program code developer, and whether functions that do not exist in the source code are included due to infection of the IDE (S205).

Subsequently, the pointer sanitizer 200 calculates the stack position and size of the tasks using the uC / OS source code and symbol information. (S206)

Then, it is checked whether there is a pointer variable in the source code of the task, and whether the memory address is hard-coded in the pointer variable (S207).

Subsequently, if the address value input to the pointer variable is outside the stack range of the corresponding task, it is detected. (S208)

The function sanitizer 100 generates a call graph from executable code.

From the generated call graph, it is possible to understand the function names used by system and program code developers and the call relationships between functions.

In the present invention, the function list of the task related to the actual operation developed by the program code developer is compared with the signature DB (Database) to examine stability.

The signature DB manages standard function names that are not allowed in the development manual or vulnerable standard function names as signatures.

Table 1 is a list of functions that can adversely affect security and safety, and consists of 'Buffer Overflow vulnerability function' and 'Memory vulnerability related function'.

Functions that are vulnerable to buffer overflow, such as ' trcat () ', trcpy () ',' strncpy () ',' sprintf () ',' vsprintf () ',' gets () ',' fscanf () ',' scanf ( ) ' .

Also, 'calloc ()', 'free ()', 'malloc ()', 'realloc ()', 'memcpy ()', 'memset ()', and 'memmove ()' are functions related to memory manipulation. It can contain.

After detecting the use of an unsafe function through the function sanitizer 100, it is possible to determine which function is used in which position through the call graph.

Therefore, the result of the function sanitizer 100 can be easily compared with the source code, and whether unnecessary functions are included due to developer mistakes or malicious actions, and whether functions that do not exist in the source code are included due to infection of the IDE. It can provide a basis for judgment.

And the pointer sanitizer 200 in detail as follows.

In the case of uC / OS, which is an embedded RTOS, it consists of a single address space, so it is possible to enter the address directly into a pointer variable and modulate the memory address value of the data area through pointer operation.

These behaviors are generally restricted by embedded standard coding rules or PLC program manuals.

The pointer sanitizer 200 according to the present invention is first performed on the machine code, and if necessary, extracts and performs necessary information through source code analysis.

The pointer sanitizer 200 detects a command pattern for hard coded address assignment to a pointer variable.

In order to detect whether the pointer variable is abnormally operated using the machine code, it is necessary to check the use of the pointer variable in the machine code.

To this end, the binary code is disassembled to check the abnormal usage pattern of the pointer variable at the assembly level.

In addition, to improve the validity and accuracy of the pointer sanitizer 200, a method of calculating the range of each task's stack through source code and symbol information and detecting a pointer operation outside the address range assigned to each task is also applied. can do.

The pattern DB manages code patterns necessary to detect pointer variable operations.

In order to generate a signature to be retained in the pattern DB, the assembly usage pattern for the CPU of the PLC to which the present invention is applied is analyzed.

The pattern to be detected in the present invention consists of a command (s) for allocating a hardcoded address value to a pointer variable and a command (s) for changing the value of the address address pointed to by the pointer variable.

That is, the pointer sanitizer 200 uses a pattern made of a combination of assembly or machine code.

If it is not easy to identify the hardcoded memory address value using only assembly code, the hardcoded memory address value is identified by analyzing the source code.

The pointer sanitizer 200 calculates the stack position and size of tasks using uC / OS source code and symbol information.

After that, check if there is a pointer variable inside the source code of the task, and check if the memory address is hard-coded in the pointer variable. Then, it detects when the address value input to the pointer variable is outside the stack range of the task.

The configuration and operation of the apparatus and method for supporting secure programming for the PLC based on the coding rule according to the present invention including such a configuration will be described in detail as follows.

3 is a configuration diagram showing an example of uC / OS code including strcpy.

Based on the coding rule according to the present invention, in order to apply a device and a method for supporting safe programming for PLC, a simple source code including a 'strcpy ()' function is written, and an execution code is generated and compiled to generate an experimental board. Was downloaded to.

'strcpy ()' is a typical function that has a buffer overflow vulnerability, and it is recommended to refrain from using it in terms of secure coding because of security problems.

Figure 3 shows some of the uC / OS source codes written by hand that include the 'strcpy ()' function.

In FIG. 3, the part where the risk of buffer overflow exists (1) is the strcpy () function inside the vul_func function.

If a string longer than the string array declared in (2) enters the second argument of the strcpy () function, a buffer overflow occurs, which may cause unintended behavior by the developer.

A denial of service attack is possible by entering a very long string as a function argument in (3), which calls the vul_func function in (1).

The program including the pointer operation is as follows.

4 is a block diagram showing an example of a code for performing a pointer operation, and FIG. 5 is a block diagram showing a result of modulating a memory value through manipulation of a pointer variable.

In the case of uC / OS, since it is a single address space system, it is possible to easily modulate the memory value of an arbitrary data area through a pointer variable.

For example, in FIG. 4, source code is written in which one task (App_Task2) manipulates a function pointer variable of another task (App_Task1).

This situation is an operation prohibited by the embedded standard coding rule, and is not allowed in general-purpose operating systems such as MS Windows and Linux.

In general, one task should not read / write the variable of another task, but the address of the function pointer variable ((3) in Figure 4) declared in another task in (4) of the pointer variable in Figure 4 By hard-coding and manipulating, we can finally modulate the value of the function pointer variable a with print_hacked ().

5 shows the result of calling a function pointer variable modulated by another task.

Through this, it is possible to call an unintended function by modulating the value of the function pointer, or an attack that modulates the memory value of an arbitrary area.

The implementation of the sanitizer is as follows.

 FIG. 6 is a call graph of a uC / OS task, and FIG. 7 is an assembly code configuration diagram of FIG. 4.

As a prerequisite for implementing a function sanitizer, you need to create a call graph.

In one embodiment of the present invention, a tool that analyzes machine code provided by TI and outputs a function call graph was used.

FIG. 6 shows a call order of a task in a function call graph output in machine language code including the source code of FIG. 3.

6, it is possible to extract all function names that are called while the task is operating.

The function sanitizer detects that the 'strcpy ()' function, which is vulnerable to buffer overflow, is included in the task by comparing the signature DB with the extracted function names as a string, and warns the program code developer.

In order to apply pointer sanitizer targeting machine code, we disassemble the machine code and analyze the assembly code.

7 is assembly code corresponding to the task source code of FIG. 4.

XAR stands for General Purpose Register, and SP stands for Stack Pointer.

7 (1) and (2) show that an address is assigned as a function name to the function pointer variable a. (3) and (4) show that the address of the variable a of App_Task1 is hard-coded in the pointer variable ptr. (5) shows that the value of the memory address pointed to by the pointer variable ptr is changed to print_hacked ().

The assembly codes of (3) and (4) shown in FIG. 7 may be patterns to be detected by the pointer sanitizer. However, a pattern similar to the assembly code of (3) and (4) is detected in the entire assembly code, and is not suitable as a pattern for pointer sanitizing.

For example, in (1) and (2), it is not the source code that hardcodes the pointer variable, but it can be confirmed that it is similar to the assembly code of (3) and (4).

Therefore, by adding the assembly code of (5) that changes the value of the memory address indicated by the pointer variable, the patterns of (3) to (5) were added to the detection pattern DB of the pointer sanitizer. In the experiment using this pattern, it was confirmed that the corresponding code pattern was detected.

8 is a block diagram showing an example of a code pattern for a pointer sanitizer.

8 shows a pattern for modulating a memory value using a pointer variable.

The empty line between (2) and (3) in FIG. 8 is a situation in which arbitrary assembly code is executed after allocating a memory address to the pointer variable and then modulating the memory address value indicated by the pointer variable. Seems to be considering.

Another assembly code may be inserted depending on the time when the memory value is modulated after the command (2).

In the case of (3), the operator can be changed to MOV, MOVL, MOVB, etc. according to the second operand.

As in the example of FIGS. 7 and 8, identifying a hardcoded address value with only assembly code has the potential for false negatives.

However, if the source code of FIG. 4 is analyzed, it can be easily understood that only App_Task2 uses a hard-coded address value.

Therefore, if the source code analysis is used at the same time, the accuracy of detecting an unsafe pointer operation can be improved.

In order to implement pointer sanitizer using source code and symbol information, it is necessary to check the position and size of each task stack.

9 is a configuration diagram showing an example of a uC / OS code prototype for generating a task.

9 is a prototype of a function for generating a task among uC / OS codes.

In FIG. 9, the first argument (App_Task2) used when creating the task is a pointer indicating the starting point of the task code, and the third argument (App_TaskPostStk []) is a pointer indicating the starting position of the task stack.

The location indicated by the App_TaskPostStk [] argument can check the memory address through symbol information.

In addition, if the value of the argument (APP_CFG_TASK_STK_SIZE) that specifies the size of the stack is used, the stack range of the task can be checked.

10 is a configuration diagram showing an example of symbol information for executable code.

10 is a part of symbol information for executable code.

Through this, the starting position of the task stack can be obtained and the range of the stack can be calculated.

Using the information in FIG. 10, it can be confirmed that the stack range of App_Task2 is 0xe040 to 0xe1c0.

If the memory address value is hard-coded directly in the pointer variable ptr in App_Task2 in FIG. 4 using this information, it is not the stack range of App_Task2 and detects this to warn the program code developer.

An apparatus and method for supporting secure programming for a PLC based on the coding rule according to the present invention described above, in order to enhance security of a PLC using uC / OS, execute code to be downloaded directly to the PLC. It implements an executable code sanitizer that detects and detects vulnerable library functions and pointer operations that are not intended by program code developers.

According to the present invention, it is possible to enhance the security of the PLC by pre-detecting even when a developer accidentally uses an inappropriate function and pointer operation, or when an IDE infected with malicious code randomly adds a malicious library function.

It will be understood that the present invention is implemented in a modified form without departing from the essential characteristics of the present invention as described above.

Therefore, the specified embodiments should be considered in terms of explanation rather than limitation, and the scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the equivalent range are included in the present invention. Should be interpreted.

100. Function sanitizer
200. Pointer Sanitizer

Claims (19)

A function sanitizer that generates call graphs from executable code and detects functions that are not allowed in the standard library functions or coding rules manual that can adversely affect the PLC;
After disassembling the execution code, it detects anomaly operation patterns for pointer variables, and uses source code and symbol information to detect memory value settings or changes that can be a threat to security and safety. Pointer sanitizer;
The function sanitizer and the pointer sanitizer, and the execution code sanitizer is configured,
The executable code sanitizer is statically analyzed before downloading the executable code from the integrated development environment (IDE) to the PLC, and standard library functions and coding rules that can adversely affect the PLC detected by the function sanitizer Secure programming for PLC based on coding rules characterized by allowing functions that are not allowed in the manual to be identified and removed by setting or changing memory values that may threaten security and safety detected by the pointer sanitizer. Device to support. The method of claim 1, wherein the function sanitizer,
Compare the function list of the task represented by the execution code developed by the program code developer with the signature DB (Database),
The function list of the task includes a function name extracted through the call graph generated from the execution code, and is a device for supporting secure programming for PLC based on coding rules. 3. The apparatus of claim 2, wherein the signature DB manages a standard function name that is not allowed in a development manual or a weak standard function name as a signature, and is based on a coding rule. According to claim 2, The function list that can adversely affect the security and safety in the function sanitizer is composed of 'Buffer Overflow vulnerability function' and 'Memory vulnerability related function',
Buffer Overflow vulnerable functions such as ' trcat () ', trcpy () ',' strncpy () ',' sprintf () ',' vsprintf () ',' gets () ',' fscanf () ', and' scanf () '
Memory vulnerability related functions include 'calloc ()', 'free ()', 'malloc ()', 'realloc ()', 'memcpy ()', 'memset ()', and 'memmove ()' Device to support secure programming for PLC based on the coding rule. The method of claim 1, wherein the function sanitizer,
Generate a call graph from the executable code, analyze the function names and call relationships between functions used by system and program code developers from the generated call graph,
After comparing the function list of the task represented by the execution code developed by the program code developer with the signature DB (Database), after detecting the standard library functions that can adversely affect the PLC or functions that are not allowed in the coding rules manual, Through the graph, the function sanitizer determines which function is used at which position,
Based on the coding rule characterized by comparing the results obtained by the function sanitizer with the source code and determining whether standard library functions that can adversely affect the PLC by program code developers or functions that are not allowed in the coding rule manual are included. Device to support secure programming for PLC. According to claim 1, The pointer sanitizer,
Performs anomaly operation pattern detection operation on the pointer variable targeting the execution code,
If it is difficult to detect anomaly operation pattern targeting the execution code, the information necessary for anomaly operation pattern detection is extracted through source code analysis,
A device to support secure programming for PLC based on coding rules, characterized in that it detects a command pattern that sets a specific value by hardcoding an address directly into a pointer variable. The method of claim 6, wherein the pointer sanitizer,
Through the source code and symbol information, the scope of each task's stack is expressed as executable code developed by the program code developer.
Using the argument (App_Task2) as a pointer to the starting point of the task code, and the argument (App_TaskPostStk []) as a pointer to the starting position of the task stack,
The location indicated by App_TaskPostStk [] is calculated by checking the stack address of the task using the value of the argument (APP_CFG_TASK_STK_SIZE) that identifies the memory address through symbol information, and
A device for supporting secure programming for PLC based on coding rules, which is characterized by improving the validity and accuracy by detecting pointer operations outside the range of addresses assigned to each task. The pointer sanitizer of claim 7,
Includes a pattern DB that manages the code patterns needed to detect pointer variable operations,
Device for supporting secure programming for PLC based on coding rules, characterized by analyzing the assembly usage pattern for the CPU of the target PLC to generate the signature to be maintained in the pattern DB. According to claim 8, The pattern to be detected by the pointer sanitizer,
A device for supporting secure programming for PLC based on coding rules, characterized by consisting of instructions for assigning hardcoded address values to pointer variables and instructions for changing the address address value pointed to by pointer variables. The pointer sanitizer of claim 9,
In order to apply pointer sanitizer targeting machine code, we assemble machine code and analyze assembly code.
When performing anomaly operation pattern detection operation on a pointer variable,
Identifies hard-coded memory address values using only assembly code, or
A device for supporting secure programming for PLC based on coding rules, characterized by analyzing the source code and identifying hard-coded memory address values. delete By analyzing the executable code in the integrated development environment (IDE) before downloading it to the PLC, it identifies the standard library functions that can adversely affect the PLC detected by the function sanitizer or functions that are not allowed in the coding rules manual. In order to be able to remove it,
A function sanitizer generating a call graph from executable code;
Analyzing function names and call relationships between functions used by system and program code developers from the generated call graph;
Comparing a function list of a task represented by executable code developed by a program code developer with a signature DB (Database);
Detecting standard library functions that may adversely affect the PLC or functions that are not allowed in the coding rule manual, and using a call graph to determine which functions are used at which positions;
And comparing the results obtained by the function sanitizer with the source code to determine whether standard library functions that can adversely affect the PLC by program code developers or functions that are not allowed in the coding rule manual are included. A method to support secure programming for PLC based on coding rules. 13. The method of claim 12, wherein the signature DB manages a standard function name that is not allowed in a development manual or a weak standard function name as a signature based on a coding rule. The function list of claim 12, wherein the function list that can adversely affect security and safety in the function sanitizer is composed of a 'Buffer Overflow vulnerable function' and a 'Memory vulnerability related function'.
Buffer Overflow vulnerable functions such as ' trcat () ', trcpy () ',' strncpy () ',' sprintf () ',' vsprintf () ',' gets () ',' fscanf () ', and' scanf () '
Memory vulnerability related functions include 'calloc ()', 'free ()', 'malloc ()', 'realloc ()', 'memcpy ()', 'memset ()', and 'memmove ()' A method for supporting secure programming for PLC based on the coding rule. In the integrated development environment (IDE), the executable code is statically analyzed before being downloaded to the PLC so that the pointer sanitizer can detect and remove the memory value setting or change that may be a threat to security and safety. in order to,
Pointer The range of each task's stack represented by the execution code developed by the program code developer through source code and symbol information through the source code and symbol information, the argument (App_Task2) that points to the starting point of the task code, and the starting position of the task stack. Using the pointer argument (App_TaskPostStk []), the location indicated by App_TaskPostStk [] checks the memory address through symbol information, and the task's stack range is checked using the value of the argument specifying the stack size (APP_CFG_TASK_STK_SIZE). To calculate;
Checking whether a pointer variable exists in the source code of the task, and checking whether a memory address is hard-coded in the pointer variable;
A method for supporting secure programming for a PLC based on a coding rule, comprising: detecting when the address value input to the pointer variable is outside the stack range of the corresponding task. The pointer sanitizer of claim 15,
Performs anomaly operation pattern detection operation on the pointer variable targeting the execution code,
If it is difficult to detect anomaly operation pattern targeting the execution code, the information necessary for anomaly operation pattern detection is extracted through source code analysis,
A method for supporting secure programming for PLC based on coding rules, characterized by detecting a command pattern that sets a specific value by hardcoding an address directly into a pointer variable. The pointer sanitizer of claim 16,
Includes a pattern DB that manages the code patterns needed to detect pointer variable operations,
A method for supporting secure programming for PLC based on coding rules, characterized by analyzing the assembly usage pattern for the CPU of the target PLC to generate the signature to be maintained in the pattern DB. The method of claim 16, wherein the pattern to be detected by the pointer sanitizer is:
A method for supporting secure programming for PLC based on coding rules, which consists of instructions for assigning hardcoded address values to pointer variables and instructions for changing the address address value pointed to by pointer variables. The pointer sanitizer of claim 16,
In order to apply pointer sanitizer targeting machine code, we assemble machine code and analyze assembly code.
When performing anomaly operation pattern detection operation on a pointer variable,
Identifies hard-coded memory address values using only assembly code, or
A method for supporting secure programming for PLC based on coding rules, characterized by analyzing the source code and identifying hard-coded memory address values.

Images