WO2021201433A1 - Dispositif et procédé de prévention d'attaque de falsification de got à base de cfi - Google Patents

Dispositif et procédé de prévention d'attaque de falsification de got à base de cfi Download PDF

Info

Publication number
WO2021201433A1
WO2021201433A1 PCT/KR2021/002188 KR2021002188W WO2021201433A1 WO 2021201433 A1 WO2021201433 A1 WO 2021201433A1 KR 2021002188 W KR2021002188 W KR 2021002188W WO 2021201433 A1 WO2021201433 A1 WO 2021201433A1
Authority
WO
WIPO (PCT)
Prior art keywords
branch
library
calling program
identifier
validation
Prior art date
Application number
PCT/KR2021/002188
Other languages
English (en)
Korean (ko)
Inventor
신동규
정승훈
Original Assignee
세종대학교산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 세종대학교산학협력단 filed Critical 세종대학교산학협력단
Publication of WO2021201433A1 publication Critical patent/WO2021201433A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements

Definitions

  • the description below relates to the GOT tampering attack prevention technique.
  • Control flow takeover attack refers to an act of taking control of a program by changing the execution flow of the program to the program code address intended by the attacker by 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.
  • 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.
  • the Full Relro technique causes a delay in loading time, and there is a problem that it cannot be applied to library files.
  • 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.
  • 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.
  • GOT Global Offset Table
  • the performing of the branch validation may include 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.
  • 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.
  • PLT Procedure Linkage Table
  • 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.
  • 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.
  • the GOT tampering attack can be blocked.
  • 1 is a diagram for explaining calling a dynamic library function in a program.
  • FIG. 2 is a block diagram for explaining the configuration of a GOT protection device according to an embodiment.
  • FIG. 3 is a flowchart illustrating a method of preventing a GOT tampering attack in the GOT protection device according to an embodiment.
  • FIG. 4 is a diagram for explaining sharing of dynamic function symbols between a program and a library, according to an embodiment.
  • FIG. 5 is a diagram for explaining checking a branch identifier in a PLT entry of a calling program, according to an embodiment.
  • FIG. 6 is a diagram for explaining a library jump table according to an embodiment.
  • FIG. 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.
  • FIG. 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.
  • FIG. 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • FIG. 2 is a block diagram for explaining the configuration of a GOT protection device according to an embodiment
  • 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 .
  • 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.
  • 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.
  • the identifier generating unit 210 may generate a branch identifier by coding a dynamic binding symbol shared between the calling program and the library.
  • 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, and if the compared results do not match, the GOT entry value can be reset.
  • PLT Provide Linkage Table
  • 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.
  • 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
  • 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.
  • FIG. 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.
  • 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.
  • different programs calling the same library function include an entry for the same library file in the '.dynamic' section of each ELF file and an entry for the same function symbol in the '.dynsym' section. can be checked
  • 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 causes a duplicated symbol error, so the 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.
  • the same function name in a different format may be defined by a template declaration or the like.
  • the following coding process may be performed for a dynamic binding symbol to be used as a branch identifier.
  • 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 for binding, and since there is no redundancy, there is no need for a separate name decoration for generating identifiers.
  • FIG. 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.
  • 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.
  • the GOT entry In the first call, there is no branch identifier code at the address indicated by the initial value of the GOT entry.
  • 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.
  • the GOT protection device can create a library jump table.
  • the branch identifier code For branch validation in the PLT entry, the branch identifier code must be inserted into the library code.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • analysis and code optimization in units of input files may be performed.
  • the implemented Pa ss lists the functions defined rather than the local connection properties in the module, 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 CFI implementations based on function type validation of other compilers (eg, LLVM).
  • the symbol of the jump table entry has 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 property, so that all codes that referenced the existing function symbol, including the external call module, refer to the jump table entry.
  • 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.
  • 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 a branch identifier 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the linker 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.
  • FIG. 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.
  • the binary size of the module increases.
  • 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 ⁇ .
  • 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.
  • 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 .
  • each jump table entry may be created for each defined global function in the library.
  • 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 a 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 dynamic library libinproctrace.so included in the binutils-gdb program group. It is the result of comparing the binary size information before and after application of each tamper attack prevention operation.
  • the binutils-gdb program group contains 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 dependent on the binutils-gdb program group 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
  • 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.
  • FIG. 11 is a diagram for explaining changing a relocation entry and a loading time in Full/Partial Relro.
  • 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. .
  • 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.
  • the function of the external link property is duplicated, it is not considered because it fails in the link process.
  • functions of weak connection properties may be redundantly placed in the process space.
  • 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
  • the possibility of overlapping function symbols and branch identifiers can be analyzed for gdb , which has the largest process space code area.
  • gdb may load all libraries except liblto_plugin.so among the libraries that the binutils-gdb program group included in FIG. 10 depends on.
  • 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.
  • the protection target is the same for the Full Relro technique and the CFI-based GOT forgery attack prevention method proposed in the embodiment.
  • loading delay may occur due to batch binding to library function symbols in the program at program loading time.
  • 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.
  • 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.
  • 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.
  • 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.
  • the individual dynamic binding time is not diminished and it is not easy to measure.
  • 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.
  • the tamper attack prevention method may be applied to the calling program and the library together.
  • 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.
  • 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.
  • the GOT protection device may check whether the library's CFI-based GOT tampering attack prevention operation is applied, and then 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.
  • 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.
  • OS operating system
  • the processing device may also access, store, manipulate, process, and generate data in response to execution of the software.
  • 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.
  • the software may comprise a computer program, code, instructions, or a combination of one or more thereof, 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un dispositif et un procédé de prévention d'attaque de falsification de GOT à base de CFI. Selon un mode de réalisation, un procédé de prévention d'attaque de falsification de table de décalage global (GOT) réalisé par un dispositif de protection de GOT mise en œuvre par ordinateur peut comprendre les étapes consistant à : générer un identifiant de branchement par codage d'un symbole de liaison dynamique partagé entre un programme d'appel et une bibliothèque; réaliser un contrôle de validité de branchement via un code de commande pour contrôler le code d'identifiant de branchement codé dans une table de branchements incluse dans le programme d'appel; et exécuter le programme d'appel via un appel de fonction depuis la table de branchements incluse dans le programme d'appel sur la base du contrôle de validité de branchement réalisé.
PCT/KR2021/002188 2020-02-26 2021-02-22 Dispositif et procédé de prévention d'attaque de falsification de got à base de cfi WO2021201433A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR20200023549 2020-02-26
KR10-2020-0038983 2020-03-31
KR1020200038983A KR102351663B1 (ko) 2020-02-26 2020-03-31 Cfi 기반 got 변조 공격 방지 장치 및 그 방법

Publications (1)

Publication Number Publication Date
WO2021201433A1 true WO2021201433A1 (fr) 2021-10-07

Family

ID=77785182

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/002188 WO2021201433A1 (fr) 2020-02-26 2021-02-22 Dispositif et procédé de prévention d'attaque de falsification de got à base de cfi

Country Status (2)

Country Link
KR (1) KR102351663B1 (fr)
WO (1) WO2021201433A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102567924B1 (ko) * 2021-11-01 2023-08-17 부산대학교 산학협력단 웹 어셈블리에서의 간접호출 명령어 보호를 위한 장치 및 방법

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2256659A1 (fr) * 2009-05-27 2010-12-01 NTT DoCoMo, Inc. Procédé et appareil pour la prévention de modification du flux d'exécution d'un programme
KR20120006334A (ko) * 2010-07-12 2012-01-18 고려대학교 산학협력단 프로그램 카운터 인코딩을 이용한 간접 함수 호출 보호 방법 및 보호 장치
US20150356294A1 (en) * 2014-06-09 2015-12-10 Lehigh University Methods for enforcing control flow of a computer program
KR101955356B1 (ko) * 2017-12-08 2019-03-07 한국인터넷진흥원 취약 함수 사용에 의한 취약점을 보완하기 위한 바이너리 패치 장치 및 그 방법
JP2019121203A (ja) * 2018-01-09 2019-07-22 株式会社Ａｔｔｃ 変換装置、変換プログラム、プログラム変換方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2256659A1 (fr) * 2009-05-27 2010-12-01 NTT DoCoMo, Inc. Procédé et appareil pour la prévention de modification du flux d'exécution d'un programme
KR20120006334A (ko) * 2010-07-12 2012-01-18 고려대학교 산학협력단 프로그램 카운터 인코딩을 이용한 간접 함수 호출 보호 방법 및 보호 장치
US20150356294A1 (en) * 2014-06-09 2015-12-10 Lehigh University Methods for enforcing control flow of a computer program
KR101955356B1 (ko) * 2017-12-08 2019-03-07 한국인터넷진흥원 취약 함수 사용에 의한 취약점을 보완하기 위한 바이너리 패치 장치 및 그 방법
JP2019121203A (ja) * 2018-01-09 2019-07-22 株式会社Ａｔｔｃ 変換装置、変換プログラム、プログラム変換方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JEONG SEUNGHOON; HWANG JAEJOON; KWON HYUKJIN; SHIN DONGKYOO: "A CFI Countermeasure Against GOT Overwrite Attacks", IEEE ACCESS, IEEE, USA, vol. 8, 19 February 2020 (2020-02-19), USA, pages 36267 - 36280, XP011775299, DOI: 10.1109/ACCESS.2020.2975037 *

Also Published As

Publication number Publication date
KR20210108848A (ko) 2021-09-03
KR102351663B1 (ko) 2022-01-17

Similar Documents

Publication Publication Date Title
Williams-King et al. Egalito: Layout-agnostic binary recompilation
US8434064B2 (en) Detecting memory errors using write integrity testing
Dang et al. The performance cost of shadow stacks and stack canaries
Niu et al. Modular control-flow integrity
US9390261B2 (en) Securing software by enforcing data flow integrity
Castro et al. Securing software by enforcing data-flow integrity.
Zeng et al. Combining control-flow integrity and static analysis for efficient and validated data sandboxing
CN109918903B (zh) 一种基于llvm编译器的程序非控制数据攻击防护方法
US6151618A (en) Safe general purpose virtual machine computing system
US8352797B2 (en) Software fault isolation using byte-granularity memory protection
Arnold et al. Ksplice: Automatic rebootless kernel updates
Niu et al. Monitor integrity protection with space efficiency and separate compilation
Akritidis et al. Preventing memory error exploits with WIT
US7603704B2 (en) Secure execution of a computer program using a code cache
US7886148B2 (en) Secure execution of a computer program
US7555592B1 (en) Kernel acceleration technology for virtual machine optimization
Mashtizadeh et al. Cryptographically enforced control flow integrity
CN110598405B (zh) 一种运行时访问控制方法及计算装置
JP2022065654A (ja) 無効なメモリ参照に対する保護のためのシステム、コンピュータ実装方法、およびコンピュータプログラム製品（無効なメモリ参照に対する保護）
Saito et al. A survey of prevention/mitigation against memory corruption attacks
WO2021201433A1 (fr) Dispositif et procédé de prévention d'attaque de falsification de got à base de cfi
CN115617687B (zh) 程序插桩方法、装置、设备和存储介质
WO2015046775A1 (fr) Procédé de vérification de l'intégrité d'un programme au moyen d'un hachage
Zhu et al. Diffguard: Obscuring sensitive information in canary based protections
US11055202B1 (en) Compilation scheme for tagged global variables

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21779557

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21779557

Country of ref document: EP

Kind code of ref document: A1