KR20210108848A - Cfi-based protection device and method for defending against got overwrite attacks - Google Patents

Abstract

Disclosed are a control flow integrity (CFI) based global offset table (GOT) modulation attack defending apparatus and a method thereof. According to an embodiment, the GOT modulation attack defending method performed by a GOT protection apparatus implemented by a computer comprises: a step of coding a dynamic binding symbol shared between a calling program and a library to generate a branch identifier; a step of performing a branch validity check through a command code to check the coded branch identifier in a branch table included in the calling program; and a step of executing the calling program through function calling from the branch table included in the calling program based on the performed branch validity check.

Description

CFI-BASED PROTECTION DEVICE AND METHOD FOR DEFENDING AGAINST GOT OVERWRITE ATTACKS

The description below relates to the GOT tampering attack prevention technique.

A control flow takeover attack refers to an act of taking control of a program by changing the execution flow of a program to an intended program code address by an attacker using a memory error vulnerability such as a buffer overflow. The GOT (Global Offset Table) tampering attack is one of the traditional control flow hijacking techniques for software privilege hijacking in a Unix-like system environment, and uses the dynamic binding device of the ELF (Executable and Linkable Format) program. The ELF program includes a branch table named PLT (Procedure Linkage Table) for each library function that is called. This entry command code refers to the GOT entry value that the dynamic linker finds and binds to the address value when the corresponding library function is called. do. GOT attack is an attack technique that modulates this GOT entry into the attacker's branch target address and steals the control flow when the corresponding library function is called in the program.

Among the techniques to prevent GOT tampering, the Full Relro technique that completes address relocation when ELF file is loaded and makes the GOT area read-only is used as an effective defense technique to prevent GOT tampering attacks. However, the Full Relro technique causes a delay in loading time, and there is a problem that it cannot be applied to library files. In particular, the recent sophisticated code reuse attack technique enables the library GOT attack, so there is a problem that the Full Relro technique can no longer defend.

It is possible to provide a method and device for effectively blocking GOT attacks while minimizing the loading delay and performance overhead of executable files, including library files, which could not be defended in Full Relro.

It is possible to provide a GOT protection apparatus and method using a Control Flow Integrity (CFI) technique.

A GOT tampering attack prevention method performed by a computer-implemented Global Offset Table (GOT) protection device includes: generating a branch identifier by coding a dynamic binding symbol shared between a calling program and a library; performing branch validation through an instruction code for checking the coded branch identifier code in a branch table included in the calling program; and executing a calling program through a function call from a branch table included in the calling program based on the performed branch validation check.

The performing of the branch validation check includes inserting the generated branch identifier into the library, and checking the coded branch identifier code in the branch identifier inserted into the library and the calling program PLT (Procedure Linkage Table) entry. Compares the value located at the branch target point indicated by the GOT entry through the command code added for may include the step of

The step of performing the branch validation check is to determine whether to perform the branch validation check when a call is made while the CFI-based GOT tampering attack prevention method is applied to any one of the calling program or library according to the execution environment of the program. may include steps.

The performing the branch validation check may include not performing the branch identifier check when the CFI-based GOT tampering attack prevention method is not applied to the calling program.

The performing of the branch validation may include determining whether to add a branch validation code by checking whether the library includes a branch identifier when the CFI-based GOT tampering attack prevention method is not applied to the library. may include.

In the step of performing the branch validation, if the library includes a branch identifier, inserting an instruction code including a branch identifier into the PLT entry of the calling program, and if the library does not include a branch identifier, The method may include directly calling the calling program through symbol binding by the dynamic linker.

A computer-implemented Global Offset Table (GOT) protection device includes: an identifier generator generating a branch identifier by coding a dynamic binding symbol shared between a calling program and a library; a validity check unit that performs branch validation through an instruction code for checking the coded branch identifier code in the branch table included in the calling program; and a program execution unit executing a calling program through a function call from a branch table included in the calling program based on the performed branch validation check.

The validity check unit inserts the generated branch identifier into the library, and checks the branch identifier inserted into the library and the coded branch identifier code in the calling program Procedure Linkage Table (PLT) entry. value located at the branch target point indicated by the GOT entry is compared through , branching is performed when the compared result values match, and when the compared result values do not match, the GOT entry value can be reset.

The validation unit may determine whether to perform the branch validation check when a call is made while the CFI-based GOT tampering attack prevention method is applied to any one of the calling program or library according to the execution environment of the program.

The validity check unit may not perform branch identifier check when the CFI-based GOT tampering attack prevention method is not applied to the calling program.

When the CFI-based GOT tampering attack prevention method is not applied to the library, the validation unit may determine whether to add a branch validation code by checking whether the library includes a branch identifier.

The validity check unit inserts an instruction code including a branch identifier into the PLT entry of the calling program when the library includes a branch identifier, and when the library does not include a branch identifier, a symbol generated by the dynamic linker The calling program can be directly called through binding.

By using the dynamic binding function symbol as the branch identifier of the CFI and checking the branch identifier code coded in the library jump table at the PLT call point of the calling program, the GOT tampering attack can be blocked.

In addition, it is possible to effectively block GOT attacks while minimizing the loading delay and performance overhead of executable files, including library files, which could not be defended in Full Relro.

In addition, gradual build is possible by minimizing performance overhead, and it has high compatibility with existing libraries.

1 is a diagram for explaining calling a dynamic library function in a program.
2 is a block diagram for explaining the configuration of a GOT protection device according to an embodiment.
3 is a flowchart illustrating a method of preventing a GOT tampering attack in the GOT protection device according to an embodiment.
4 is a diagram for explaining sharing of dynamic function symbols between a program and a library, according to an embodiment.
5 is a diagram for explaining checking a branch identifier in a PLT entry of a calling program, according to an embodiment.
6 is a diagram for explaining a library jump table according to an embodiment.
7 is an example for explaining the implementation of a library jump table with respect to an example program that calls a library function according to an embodiment.
8 is a diagram for explaining branch verification in a calling program according to an embodiment.
9 is an example for explaining file size information of a program group according to an embodiment.
10 is a diagram for explaining file size information of a library called by a program group according to an embodiment.
11 is a diagram for explaining the number of relocation and loading times of the dynamic linker according to different techniques for each program, according to an embodiment.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

1 is a diagram for explaining calling a dynamic library function in a program.

Unix-like static linker can create two structures PLT and GOT to support dynamic library linking and include them as a section of the calling program's ELF file. In this case, the dynamic library linking is a technique that allows the symbol binding process for a function between the calling program and the library to be performed dynamically at run time. The dynamic linker and the static linker work together to enable symbol binding between modules. The PLT is a function call table that links the calling program and the library function, and is included in the final executable program or library file unit by the static linker. The static linker creates a PLT entry for each library function call, and the original function call statement can be modified with an offset direct branch to the PLT entry. The PLT entry may contain instruction code that executes an indirect call to the target branch address by referring to the value of the paired GOT entry. GOT is a pointer array structure containing runtime address values of library functions that are dynamically bound to the calling program. As mentioned above, address values can be stored by the dynamic linker.

In the embodiment, a method for preventing a GOT tampering attack and a GOT protection device to which Control Flow Integrity (CFI) is applied will be described. The CFI technique may consist of an analysis step of generating a normal control flow graph and a step of inserting a branch validation code so that a control flow branch is made under the normal control flow graph at execution time.

The GOT tampering attack prevention method to which CFI is applied, as proposed in the embodiment, assumes an execution environment in which a general Linux defense technique operates and a strong attack model. Executable program and library files target ELF files, and memory pages are not writeable at the same time as execution by DEP. At a level that does not cause excessive program errors, an attacker can read or write any data page memory or read code page memory through memory tampering and information leak attacks. Partial Relro is applied to program and library files, and external library calls of programs are made through PLT/GOT. The attacker attempts a control flow takeover attack by tampering with the GOT table entry of a program or library. As shown in Fig. 1, it is possible to propose a method and apparatus for preventing GOT tampering attacks for inter-module calls in a program execution environment.

2 is a block diagram for explaining the configuration of a GOT protection device according to an embodiment, and FIG. 3 is a flowchart for explaining a method of preventing a GOT tampering attack in the GOT protection device according to an embodiment.

The processor included in the GOT protection device 100 may include an identifier generation unit 210 , a validity check unit 220 , and a program execution unit 230 . Such a processor and components of the processor may control the GOT protection device to perform steps 310 to 330 included in the method for preventing a GOT tampering attack of FIG. 3 . In this case, the processor and components of the processor may be implemented to execute instructions according to the code of the operating system and the code of at least one program included in the memory. Here, the components of the processor may be expressions of different functions performed by the processor according to a control command provided by the program code stored in the GOT protection device 100 .

The processor may load the program code stored in the file of the program into the memory for a method of preventing a GOT tampering attack. For example, when a program is executed in the GOT protection device 100 , the processor may control the GOT protection device to load a program code from a file of the program into the memory according to the control of the operating system.

In step 310, the identifier generating unit 210 may generate a branch identifier by coding a dynamic binding symbol shared between the calling program and the library.

In step 320 , the validity check unit 220 may perform branch validity check through the command code for checking the branch identifier code coded in the branch table included in the calling program. The validation unit 220 inserts the generated branch identifier into the library, and checks the branch identifier inserted into the library and the branch identifier code coded in the calling program PLT (Procedure Linkage Table) entry through the added command code to enter the GOT entry. It is possible to compare the values located at the branching target point indicated by , and if the compared results match, branching is performed. If the compared results do not match, the GOT entry value can be reset. The validation unit 220 may determine whether to perform branch validation when a call is made while the CFI-based GOT tampering attack prevention method is applied to any one of the calling program or library according to the execution environment of the program. When the CFI-based GOT tampering attack prevention method is not applied to the calling program, the validity check unit 220 may not perform branch identifier check. When the CFI-based GOT tampering attack prevention method is not applied to the library, the validation unit 220 may determine whether to add a branch validation code by checking whether the library includes a branch identifier. When the library includes the branch identifier, the validation unit 220 inserts the instruction code including the branch identifier into the PLT entry of the calling program, and when the library does not include the branch identifier, performs symbol binding by the dynamic linker. The calling program can be called directly through

In step 330 , the program execution unit 230 may execute a calling program through a function call from a branch table included in the calling program based on the performed branch validation check.

4 is a diagram for explaining sharing of dynamic function symbols between a program and a library, according to an embodiment.

GOT protection devices can share static branch identifiers using dynamic binding symbols. In order to apply CFI to the control flow between modules, a branch identifier assignment in consideration of the library must be made. A dynamic binding function symbol is an identifier that is statically shared between the calling program and the library. The binding process of the dynamic linker can use the library list and symbol table of the calling program. Referring to Figure 4, different programs calling the same library function '. You can see that the entry for the same library file is included in the dynamic ' section and the entry for the same function symbol is included in the '.dynsym ' section. A dynamic binding function symbol can be used as a branch identifier in a PLT entry, since the function symbol bound to each linked GOT entry is unique. At this time, the symbol of the calling function is generally not uniquely determined at other indirect call branch points during static analysis.

A dynamic binding function symbol can meet the requirements of a small-sized branch identifier group. Library functions generally have the property of External Linkage, so they are uniquely identified in the process space. When there are different functions with the same name with the External Linage property during static linking, the static linker generates a duplicated symbol error, so symbol collision of the calling function does not occur at runtime. . If the symbol of the calling function has a weak linkage property, the function may be duplicated and included in multiple libraries. In this case, different addresses may be bound to the same function symbol depending on the runtime environment of the calling program, and as a result, the weakly connected symbol may form a rather large branching group. On the other hand, a function symbol of an external linkage property defined in one module may be defined as a local linkage property in another module. does not exist in ), dynamic binding function symbols can be good candidates for unique branch identifier selection.

The GOT protection device may perform coding of the dynamic binding symbol in order to use the dynamic binding function symbol as a branch identifier of the CFI. A library function symbol is a variable-length string and is not suitable for direct use as a branch identifier code. Also, in the C++ language, the same function name in a different format may be defined by a template declaration or the like. For example, the following coding process may be performed for a dynamic binding symbol to be used as a branch identifier. As an example, the GOT protection device uses a hash function to generate a bit code of a fixed length that can be loaded into one command code, but the string input to the hash function is a symbol preprocessed by the name mangling rule. Names may be used. Symbols decorated with names by the compiler are strings used by the dynamic linker when binding, and since there is no redundancy, there is no need for a separate name decoration for generating identifiers.

5 is a diagram for explaining checking a branch identifier in a PLT entry of a calling program, according to an embodiment.

The GOT protection device may check the branch identifier of the calling program PLT entry. Since the GOT protection device uses a global function symbol as a branch identifier, branch validation can be performed by executing a simple comparison statement at the branch origin. Referring to FIG. 5 , when a branch identifier table exists in the branch target module, it is an example illustrating a pseudo-algorithm of the linker for adding a branch validation command code. The GOT protection device loads the branch identifier instruction code located at the branch target point indicated by the GOT entry, compares the value obtained by loading the branch identifier instruction code with the branch identifier of the library, and if the compared values match, the branch proceeds normally; Otherwise, you can reset the GOT entry value through dynamic binding. Dynamic binding can use the Lazy Binding or Lazy Symbol Resolution device by the dynamic linker without modification. In other words, it stores the order of entries in the relocation table on the stack and branches to PLT[0] so that the dynamic linker is executed. The two instruction codes following the 'je' branch of FIG. 5 indicate the start of dynamic binding.

The instruction code of the PLT entry can be changed from an unconditional branch referencing the GOT entry value to a conditional branch with branch identifier check. In this case, a plurality of (eg, three) command codes may be added. The GOT protection device may fail the identifier check at the first invocation of the program and when the GOT entry is tampered with by an attacker. In the first call, there is no branch identifier code at the address indicated by the initial value of the GOT entry. In this case, the GOT entry can be modified to the correct function address value by the delayed binding process of the dynamic linker. It is difficult for an attacker to bypass branch validation. Assuming the above-mentioned attack model, an attacker can manipulate all GOT entries into a desired branch target address value. However, since it is impossible to modify the PLT code area, an attacker cannot tamper with the branch identifier check instruction code and the branch identifier code. Accordingly, even if the GOT entry modulation succeeds, the branch validation check of the PLT entry fails, and the modified GOT entry is updated with the correct function address by the dynamic linker to fail the control flow takeover attack by GOT modulation.

6 is a diagram for explaining a library jump table according to an embodiment. The GOT protection device can create a library jump table. For branch validation in the PLT entry, the branch identifier code must be inserted into the library code. In this case, the method of directly inserting the branch identifier code into the library function may cause an offset change of the function, which may cause additional code address relocation and compatibility problems. Accordingly, the GOT protection device can create a separate jump table for branch identifier checking so that there is no modification of an existing code section in the library. The jump table becomes an external interface of the library, and each entry in the jump table becomes an entry point for calling a library function, and can be connected to each function defined inside the library.

Referring to FIG. 6 , a call connection relationship between branch table entries and library functions is shown. Each entry code in the jump table may be composed of an instruction code including a direct branch instruction code to a corresponding library function and a branch identifier code of the corresponding function symbol. The entire jump table instruction code is created as a single independent function so that there is no additional address relocation in the existing library. In addition, the static linker can change the symbol address of the library function to point to the jump table entry so that the jump table entry address can be bound when the calling program calls the library function.

A library with jump tables enables efficient cross-module branch validation with a small amount of instruction code. The library has one entry in the jump table per calling function, and each entry contains only two instruction codes. Memory and performance overhead are limited as only one direct branch instruction code is additionally executed. The instruction code encoded with the branch identifier is loaded from the branch origin, but is not executed from the library.

7 is an example for explaining the implementation of a library jump table with respect to an example program that calls a library function according to an embodiment.

As an example, the CFI-based GOT tampering attack prevention method can be implemented based on the LLVM 10 version of the Module Pass framework and the LLD linker project, and targets the X86-64 architecture. The jump table generation code of the library is implemented as a part of the LTO (Link Time Optimization) library (LLVMgold.so) based on the Module Pass and can be input as a plug-in of the LLD linker. The branch validation of the calling program will be described as an example implemented by modifying the PLT generation code of the LLD linker.

The LLVM compiler can provide a framework for code analysis and transformation of specific units. For example, LLVM may provide a pass framework for code analysis and conversion in units of 'Module ', ' Function ', and ' Basic Block ', and may be implemented in the Module Pass step in the embodiment. In the module pass stage, analysis and code optimization in units of input files may be performed. The implemented Pa ss lists the defined functions rather than the local connection properties in the module, and composes one jump table for each module, and then creates an entry function that branches to the starting point of each function. The jump table may be constructed in a similar manner to the jump table used in the CFI implementation based on function type validation of other compilers (eg, LLVM). The symbol of the jump table entry should have the symbol name of the defined function and the external linkage attribute. The .cfi suffix is appended to the defined function symbol and converted into a local connection attribute, so that all codes that referenced the existing function symbol, including the external call module, refer to the jump table entry. Unlike the jump table implemented in other compilers (eg, LLVM), the branch identifier-encoded instruction code is placed after the branch instruction code for each entry to enable branch validation at the origin of the call. As the branch identifier, a value obtained by taking the MD5 hash value from the symbol of the decorated function and converting the upper 4 bytes into a little endian format may be used. This value may be placed in the lower 4 bytes of the prefetchnta instruction used to encode the branch identifier. 'prefetchnta' is an 8-byte X86-64 instruction code that reads the instruction code in advance from the cache and has no functional side effect during execution. 7 is an example showing the result of checking the library example source code including two global functions and the generated jump table code with the objdump command. Each jump table entry consists of 16 bytes and the three 'int3' instruction codes following the 'prefetchnta' instruction code are padding bytes for 16-byte alignment.

The module-specific jump table generation is done in the LTO stage, which performs code optimization at link time. Since the code conversion of the LTO stage requires an input module in the LLVM IR bitcode format, the input module of the linker can be compiled by using the -flto compile option to the Clang 10 compiler in the embodiment. When linking non-bitcode object modules, code conversion is not performed in the LTO stage, so the corresponding functions are not included in the jump table entry of the generation library. In the embodiment, since dynamic branching is protected, it is necessary to generate a file in LLVM IR format only for object modules to be linked as dynamic libraries, and it is not necessary to generate LLVM IR bitcodes for modules to be linked as executable files or static archives. .

Branch validation in the calling program can be implemented by modifying the PLT generation code of LLD, the linker project of LLVM. An instruction code for checking branch validity may be generated for each PLT entry. The branch identifier can be derived from the function symbol associated with the referenced GOT entry by taking the MD5 hash value in the same way as in the jump table entry. The instruction code for branch identifier check is compared with the branch identifier of a value of 4 bytes located 9 bytes away from the address pointed to by the GOT entry (5 bytes of the 'jmp' instruction code + 4 bytes of the branch identifier offset in the 'prefetchnta' instruction code). can FIG. 8 shows a PLT including a branch identifier check code as a result of applying the method proposed in the embodiment to the example program that calls the library function of FIG. 7 . If the branch identifier is the same through the 'je' instruction code, a branch to the library function is made, otherwise the instruction code for deferred binding may be executed. Each PLT entry consists of 32 bytes, and the 4 'int3' command codes following the 'jmpq' command code are padding bytes for 32-byte alignment.

A change in the PLT entry command code may affect the initial value of the GOT entry. In the case of Partial Relro, the initial value of the GOT entry points to the address of the 'pushq' instruction code that stores the relocation index to be used by the dynamic linker. In the PLT entry according to the embodiment, if branch validation fails, it branches to the 'pushq' command code to perform dynamic linking, so initialization of the GOT entry value is not separately required. Meanwhile, the GOT protection device can perform branch validation in the calling program for library functions to which control flow protection is not applied. In this case, performance overhead due to unnecessary branch identifier checking may occur, and thus, selective branch validation for each PLT entry may be provided. When a PLT entry is created by the linker, it may be determined whether the library function includes a branch table with control flow protection applied. The GOT protection device may decide whether to add the branch validation code according to whether the library supports it. In an embodiment, only when a specific string is included in the path of the library, the branch validation code may be added when the corresponding function is called.

8 is a diagram for explaining branch verification in a calling program according to an embodiment.

The GOT protection device can measure the size of the increased file size for the binutils-gdb program group to verify its effectiveness, and evaluate security, performance, and compatibility. The binutils-gdb program group contains a variety of programs that are highly utilized in Linux and suitable for test evaluation in terms of complexity and size. As an example, evaluation can be performed using binutils-gdb version 2.33 in an AMD Ryzen 3700X CPU, Ubuntu 18.04 LTS environment.

Referring to FIG. 8 , since a branch validation code is added to the calling program and a branch table is generated from the library, the binary size of the module increases. In the calling program, in the case of X86-64, the original PLT entry size is 16 bytes, but when the CFI-based GOT tampering attack prevention method according to the embodiment is applied, the PLT entry size increases to 32 bytes. Accordingly, the binary file of the calling program may be increased in size by {PLT entry number*16 bytes}.

Referring to FIG. 9 , it is a diagram for explaining the file size information of the binutils-gdb program group. It shows the increased file size information for each executable file for the binutils-gdb program group from which debug information is removed after compiling with Partial Relro. The actual binary size increase does not match the PLT size increase because of the decrease in the number of .dynamic section entries due to the application of Partial Relro, the change in the placement segment of the .got.plt section, and the difference in the number of byte padding due to segment page boundary alignment. In general, regardless of the number of PLT entries, the ratio of the size of the PLT to the total size of the binary is low. Accordingly, the increase rate of the binary size of the calling program shows a low level as shown in FIG. 9 .

Also, a branch table entry may be created for each defined global function in the library. Referring to FIG. 7 , each jump table entry may be composed of a 5-byte unconditional branch instruction code, an 8-byte instruction code in which a branch identifier is encoded, and 16-byte padding of 3 bytes for alignment. Therefore, in the case of a library, a jump table with a size of {number of function calls * 16 bytes} is included to increase the file size, and if the library includes another dependent library, the binary size may be larger by the branch validation code.

Table 1 shows the result of comparing binary size information before and after application of each tamper attack prevention action for the dynamic library libinproctrace.so included in the binutils-gdb program group.

Table 1:

For example, the binutils-gdb program group includes only one dynamic library with a small number of PLTs (53) and global call functions (6), so the file size for a large library can be measured. 10 is a diagram for explaining file size information of a library called by a program group. Referring to FIG. 10, based on the number of PLT entries of the dynamic library that the binutils-gdb program group depends on and the number of defined global functions, the estimated value of the file size increase according to the application of the tamper attack prevention operation is shown. The actual file size may differ in the page size range due to segment boundary alignment or the like. A library module may generally include more global function symbols than an executable file due to its characteristics, but the increase in the binary size to which the embodiment is applied is not large. In particular, the larger the actual file size, the lower the rate of increase due to the application of the tamper attack prevention operation. Accordingly, it can be confirmed that the file size increase of the calling program and the library module to which the embodiment is applied is an acceptable level.

11 is a diagram for explaining the number of relocation and loading times of the dynamic linker according to different techniques for each program, according to an embodiment.

11 is a diagram for explaining changing a relocation entry and a loading time in Full/Partial Relro. When the CFI-based GOT tampering attack prevention method according to the embodiment is applied, the possibility that an attacker can neutralize or bypass it may be analyzed. Referring to the cmpl command code in Fig. 8, the GOT protection device can perform branch validation by comparing a 4-byte branch identifier hard-coded at the call origin with a 4-byte branch identifier located 0x9 bytes away from the call target point. . If an attacker finds a code containing the same value as the branch identifier in the memory space of the process and modulates the GOT entry value with the address of the -0x9 point, the branch identifier check can succeed and the control flow can branch to that address. Considering the possibility of collision of MD5 hash values, there is an accidental occurrence of 4 consecutive bytes identical to the hash value, and furthermore, there is virtually no possibility that the address range starting from the -0x9 offset is composed of a set of executable attack instruction codes.

In a normal DEP environment, an attacker cannot perform a code injection attack. The security of the CFI-based GOT tampering attack prevention method according to the embodiment depends on the probability that another function having the same symbol as the calling library function can be placed in the process space and the possibility of utilizing the function as an attack code. Local connection attribute functions are excluded from consideration because they are not subject to branch identifier and branch entry creation. In addition, if the function of the external link property is duplicated, it is not considered because it fails in the link process. As mentioned above, functions of weak connection properties may be redundantly placed in the process space. However, this function set is highly likely to perform similar functions due to the nature of the weak connection property, and even if it is branched to another function in the group by an attacker, there is only a difference in optimization and there is no difference in execution result, so it can be used as an attack code is rare Among the programs included in binutils-gdb , the possibility of overlapping function symbols and branch identifiers can be analyzed for gdb , which has the largest process space code area. gdb can load all libraries except liblto_plugin.so among the libraries that the binutils-gdb program group included in FIG. 10 depends on. As a result of analyzing the 13 libraries that gdb depends on and 9,151 function symbols of all external and weak link properties included in this library, the same function symbol was not found, and there was no case of hash value collision of MD5 branch identifiers. can be checked

Referring to FIG. 11 , the loading and execution performance of the group to which Full Relro is applied to the binutils-gdb program group and the group to which Partial Relro and the CFI-based GOT tampering attack prevention method proposed in the example are applied together are compared. The Full Relro technique is currently the most widely implemented technique for protecting the GOT of an executable file, and in comparison with Partial Relro, the GOT tampering attack can be blocked by changing the .got.plt section to a read-only property. At this time, for the executable file, the protection target is the same for the Full Relro technique and the CFI-based GOT forgery attack prevention method proposed in the embodiment. In terms of performance, in the case of Full Relro, loading delay may occur due to batch binding to library function symbols in the program at program loading time. In the case of the CFI-based GOT tampering attack prevention method proposed in the embodiment, a fast loading effect by delayed binding can be obtained by applying Partial Relro, but a time delay may occur due to dynamic binding overhead and branch validation at runtime. . For example, by using the 'LD_DEBUG=statistics' dynamic linker option, the number of relocations performed by the dynamic linker for each program and the total startup time ("Total startup time in dynamic loader") can be measured. In order to eliminate the caching effect during measurement, the 'echo 3 >/proc/sys/vm/drop_caches' command may be used, and the average of 100 loading times may be measured to reduce measurement time deviation.

Referring to FIG. 11, the number of relocations and loading times of the dynamic linker by two techniques for each program are shown. As shown in FIG. may include The number of relocations increased in Full Relro is the number of relocations for function symbols that cause delay in loading time. As shown in FIG. 11( b ), a small number of function symbol relocation times may result in a significant time delay. Considering the small executable size of the binutils-gdb program group, it is estimated that the loading time overhead will be greater for large programs.

When the CFI-based GOT tampering attack prevention method proposed in the embodiment is applied, a time delay due to the runtime dynamic binding and a performance overhead due to the branch identifier check time may occur when a function is called. The total time required for dynamic binding depends on the number of called functions and may vary depending on the execution environment of the program. It is generally known that the ratio of library functions included in the executable program to be actually called is low. In addition, since each call occurs distributedly during the execution of the program, the individual dynamic binding time is not diminished and it is not easy to measure. In branch validation, three additional instruction codes are executed, and the effect is negligible when considering the context switching overhead that occurs when calling a function. Accordingly, in the embodiment, it is possible to obtain the effect of improving loading performance due to delayed binding, which is lost in Full Relro.

On the other hand, the tamper attack prevention method may be applied to the calling program and the library together. However, depending on the program execution environment, a call may occur with the CFI-based GOT tampering attack prevention method applied to only one of the calling program or library. If the CFI-based GOT tampering attack prevention method is not applied to the calling program, the execution flow can perform the existing symbol binding process and function call process without branch identifier checking. In this case, since the symbol table of the library points to the entry address of the jump table, the origin of the call may branch to the jump table rather than the target function. Thus, one direct branch overhead may occur. Conversely, if the CFI-based GOT tampering attack prevention method is not applied to the library module, the branch identifier check fails every time it is called, and symbol binding by the dynamic linker may be performed. In this case, if it is a function that is called frequently, performance degradation may occur. In other words, if the tamper attack prevention technique is applied to only one side of the module-to-module call, there is a concern about performance overhead, but there is no change in program function.

In other words, when generating the branch validation code, the GOT protection device may check whether the library's CFI-based GOT tampering attack prevention operation is applied and apply the tampering attack prevention method for each symbol. According to the embodiment, it is possible to build gradually by minimizing the performance overhead, and has high compatibility with the existing library.

The device described above may be implemented as a hardware component, a software component, and/or a combination of the hardware component and the software component. For example, devices and components described in the embodiments may include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA). , a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions, may be implemented using one or more general purpose or special purpose computers. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to execution of the software. For convenience of understanding, although one processing device is sometimes described as being used, one of ordinary skill in the art will recognize that the processing device includes a plurality of processing elements and/or a plurality of types of processing elements. It can be seen that can include For example, the processing device may include a plurality of processors or one processor and one controller. Other processing configurations are also possible, such as parallel processors.

Software may comprise a computer program, code, instructions, or a combination of one or more of these, which configures a processing device to operate as desired or is independently or collectively processed You can command the device. The software and/or data may be any kind of machine, component, physical device, virtual equipment, computer storage medium or device, to be interpreted by or to provide instructions or data to the processing device. may be embodied in The software may be distributed over networked computer systems, and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded in a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be specially designed and configured for the embodiment, or may be known and available to those skilled in the art of computer software. Examples of the computer-readable recording medium include magnetic media such as hard disks, floppy disks and magnetic tapes, optical media such as CD-ROMs and DVDs, and magnetic such as floppy disks. - includes magneto-optical media, and hardware devices specially configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine language codes such as those generated by a compiler, but also high-level language codes that can be executed by a computer using an interpreter or the like.

As described above, although the embodiments have been described with reference to the limited embodiments and drawings, various modifications and variations are possible from the above description by those skilled in the art. For example, the described techniques are performed in a different order than the described method, and/or the described components of the system, structure, apparatus, circuit, etc. are combined or combined in a different form than the described method, or other components Or substituted or substituted by equivalents may achieve an appropriate result.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

Claims (12)

A method for preventing GOT tampering attacks performed by a computer-implemented Global Offset Table (GOT) protection device, the method comprising:
encoding a dynamic binding symbol shared between the calling program and the library to generate a branch identifier;
performing branch validation through an instruction code for checking the coded branch identifier code in a branch table included in the calling program; and
executing a calling program through a function call from a branch table included in the calling program based on the performed branch validation check
A method for preventing GOT tampering attacks, comprising: According to claim 1,
The step of performing the branch validation check is,
Inserting the generated branch identifier into the library, and checking the coded branch identifier code from the branch identifier inserted into the library and the calling program PLT (Procedure Linkage Table) entry, the GOT entry is generated through the added instruction code. Comparing the values located at the indicated branching target points, performing branching if the compared result values match, and resetting the GOT entry value if the compared result values do not match
A method for preventing GOT tampering attacks, comprising: According to claim 1,
The step of performing the branch validation check is,
Determining whether to perform the branch validation when a call is made with the CFI-based GOT tampering attack prevention method applied to any one of the calling program or library according to the execution environment of the program
A method for preventing GOT tampering attacks, comprising: 4. The method of claim 3,
The step of performing the branch validation check is,
If the CFI-based GOT tampering attack prevention method is not applied to the calling program, the branch identifier check is not performed.
A method for preventing GOT tampering attacks, comprising: 4. The method of claim 3,
The step of performing the branch validation check is,
Determining whether to add a branch validation code by checking whether the library includes a branch identifier when the CFI-based GOT tampering attack prevention method is not applied to the library
A method for preventing GOT tampering attacks, comprising: The method according to claim 5,
The step of performing the branch validation check is,
When the library includes a branch identifier, the instruction code including the branch identifier is inserted into the PLT entry of the calling program. If the library does not include the branch identifier, the calling program is performed through symbol binding by the dynamic linker. Steps to call directly
A method for preventing GOT tampering attacks, comprising: In the GOT (Global Offset Table) protection device implemented by a computer,
an identifier generator for generating a branch identifier by coding a dynamic binding symbol shared between the calling program and the library;
a validity check unit that performs branch validation through an instruction code for checking the coded branch identifier code in the branch table included in the calling program; and
A program execution unit that executes a calling program through a function call from a branch table included in the calling program based on the performed branch validation check
GOT protection device including 8. The method of claim 7,
The validation unit,
Inserting the generated branch identifier into the library, and checking the coded branch identifier code from the branch identifier inserted into the library and the calling program PLT (Procedure Linkage Table) entry, the GOT entry is generated through the added instruction code. Comparing the value located at the branching target point pointed to, performing branching if the compared result value is the same, and resetting the GOT entry value if the compared result value does not match
GOT protection device, characterized in that. 8. The method of claim 7,
The validation unit,
When a call is made with the CFI-based GOT tampering attack prevention method applied to any one of the calling program or library according to the execution environment of the program, the branch validation check is performed.
GOT protection device, characterized in that. 10. The method of claim 9,
The validation unit,
If the CFI-based GOT tampering attack prevention method is not applied to the calling program, branch identifier check is not performed.
GOT protection device, characterized in that. 10. The method of claim 9,
The validation unit,
When the CFI-based GOT tampering attack prevention method is not applied to the library, it is determined whether the branch validation code is added by checking whether the library includes a branch identifier.
GOT protection device, characterized in that. The method of claim 11,
The validation unit,
When the library includes a branch identifier, the instruction code including the branch identifier is inserted into the PLT entry of the calling program. If the library does not include the branch identifier, the calling program is performed through symbol binding by the dynamic linker. to call directly
GOT protection device, characterized in that.

Images