CN116150739A - Automatic stack overflow defense method based on dynamic protection of key address - Google Patents

Abstract

The invention relates to a stack overflow automatic defense method based on dynamic protection of a key address, which comprises the following steps: after the completion of the execution of the pellee function, executing a first instruction to enable an ebp register of the original peller to be implanted into stack protection in the inner part of the pellee function, then executing a second instruction to enable an ebp register value of the pellee to point to the stack bottom, inserting piles at the next instruction of the second instruction, and detecting through a memory manager; and executing the third instruction to restore the stack space of the teller function, inserting piles at the return instruction, changing the stack memory attribute storing the return address into the second state, and then executing the return instruction to jump back to the teller function to continue executing. The invention limits the stack memory attribute of the function return address to read-only, and any attack method cannot tamper the function return address, so that the attack mode of return2shellcode is successfully defended.

Description

Automatic stack overflow defense method based on dynamic protection of key address

Technical Field

The invention relates to the technical field of software security, in particular to an automatic stack overflow defense method based on dynamic protection of a key address.

Background

A stack is a very important data structure used to save the incoming parameters, local variables, and return addresses of functions at program run-time; when the function call is executed, if the length check is not carried out on the incoming parameters or the local variables, the values of the variables can cover the return address of the function, so that the program crashes, and if the incoming parameters are carefully constructed shellcodes, the program can also have serious loopholes such as RCE; the prior art mainly has the following modes for defending stack overflow: 1. the return address is protected from tampering, typically __ stack chk guard; 2. let the data on the stack not be allowed to be executed as code, typically DEP, for defending against return2shellcode attacks; 3. the function is prevented from jumping back to other executable code, such as library functions like libc, typically ASLR.

For __ stack chk guard: when compiling code and generating binary machine code, the compiler can make ESP apply for 4-8 bytes of space (generally called __ stack_chk_guard or Canary in industry) when applying for stack space of functions. When the function is executed, a random number of 4-8 bytes is randomly generated and stored in the space. And after the function is executed, checking whether the value of the random number is changed or not when the function is returned. If the change indicates that the local variable space is out of range in the assignment process, stack overflow occurs, execution of the current program needs to be terminated, an exception is thrown out, and the whole stack space schematic diagram is shown in fig. 1. However, in this way, the compiler needs to perform static instrumentation on all functions at the head and the tail when compiling codes, which increases the codes executed by the functions, reduces the overall execution efficiency of the program, and even consumes the stack space allocated by the operating system in a short time, which is even better in the scene of a large number of function nested calls and recursions; and each function call needs to additionally allocate 4-8 bytes of space on the stack, additionally consumes stack space, only can defend a user state program, and can bypass the address stored by the canary random number when assigning values to the local variable in the function, only the memory space where the return value of the function is located, namely the space where ebp+4 is located, so that the defending mechanism of __ stack_chk_guard is completely disabled.

For the manner of DEP: as shown in FIG. 2, in order to prevent stack overflow from being maliciously utilized, the attribute of the stack memory is set to be non-executable, so that even if shellcode is written into the stack space by means of local variable assignment by people, after a ret statement is executed, the beginning position of the shellcode is successfully jumped, but the segment of shellcode is still regarded as data by a cpu and is not executed, and thus RCE loopholes on the stack are avoided. By changing the attribute of the stack memory to be non-executable, the shellcode on the stack cannot be executed, and the purpose of return2shellcode is really achieved. However, the return address of the function is not tampered, so the return address of the function can be changed through local variables, and the function can be jumped to a library function such as libc to run, thereby achieving the purpose of return2libc, and the DEP does not fundamentally solve the problem of stack overflow.

Mode for ASLR: as shown in FIG. 3, by randomly allocating addresses of the kernel and the user program, the virtual address of each loading of the code segment is made different, and the entry address of a library function such as libc in the code segment is also changed, which increases the cost of an attacker to accurately acquire the code segment, the base address of the library function and the offset position. Although the virtual address space is randomly allocated when each loading is performed, the virtual address space is also randomly allocated, only the code segment and the base address of the library function are changed, the offset of the libc internal function relative to the base address is not changed, if the absolute virtual address of a certain function can be obtained, the base address of the libc function library can be obtained by subtracting the offset from the absolute address, and then the entry addresses of other library functions can be obtained by the base address and the offset. The absolute virtual address of the function is an address which is directly written into (the local variable n+12) after the absolute address of the target function is obtained through the GOT table, and can trigger stack overflow loopholes, so that the purpose of return2libc is achieved.

It should be noted that the information disclosed in the above background section is only for enhancing understanding of the background of the present disclosure and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The invention aims to overcome the defects of the prior art, provides an automatic stack overflow defense method based on dynamic protection of a key address, and solves the defects of the prior stack overflow defense technology.

The aim of the invention is achieved by the following technical scheme: a stack overflow automatic defense method based on dynamic protection of a key address, the stack overflow automatic defense method comprising:

after the execution of the pellee function is finished, executing a first instruction to enable an ebp register of the original peller to be implanted into stack protection in the inner part of the pellee function, executing a second instruction to enable an ebp register value of the pellee to point to the stack bottom, enabling an incoming parameter and a local variable to be correctly addressed when the inner part of the pellee function is executed, inserting piles at the position of the next instruction of the second instruction to prevent the return address of the function from being tampered by a local variable assignment code executed later, and detecting through a memory manager;

and executing the third instruction to restore the stack space of the function, ensuring that the function addresses local variables in the stack, inserting piles at the return instruction, changing the stack memory attribute storing the return address into the second state, and then executing the return instruction to jump back to the function to continue execution, thereby ensuring smooth continuation of the return function.

The instrumentation at the next instruction of the second instruction prevents the return address of the function from being tampered by the subsequently executed local variable assignment code, and the detecting by the memory manager includes:

inserting piles at the next instruction of the second instruction, changing the memory attribute at the ebp+4 position into a first state, then jumping back to the original function to continue execution, once the memory block of the ebp+4 is modified by the instruction with the local variable assignment, immediately detecting the illegal operation by the memory manager, sending an interrupt notification CPU to process the exception, stopping the whole original program execution, enabling the subsequent assignment instruction of any local variable not to change the memory address value of the memory block, and protecting the accuracy of the return address after the completion of the execution of the calee.

The first state is a read-only state, the second state is a readable and writable state, and the memory occupied data for storing the return address is released after being changed into the readable and writable state, so that error reporting caused by non-writable state when other functions normally use the memory occupied here is avoided.

The stack overflow automatic defending method further comprises a pile inserting position automatic addressing step, wherein the pile inserting position automatic addressing step comprises the following steps:

acquiring an interactive function which needs to receive data from a user and is frequently interacted with the user in a user mode or a kernel mode, and acquiring an entry address and a function name of the interactive function by analyzing a file header;

calculating and obtaining the offset of the interactive function entry address relative to the libc library function base address, sequentially searching from the offset until the first and second instructions are found, calculating the absolute virtual address required by instrumentation, and dynamically instrumentation is carried out at the position of the next byte of the second instruction.

The absolute virtual address needed by the calculation pile comprises the following specific contents:

and searching offset of an entry address of the interactive function relative to the libc library function through an instruction, randomly selecting a pid of a user state process through a top instruction, checking the address mapping of the libc library function in a virtual memory in the process, obtaining the base address of the libc library function, and obtaining the absolute virtual address of the interactive function in the memory through the offset and the base address of the libc library function.

The frame selection of the stake includes:

for high-version operating systems with the linux above 3.18 and the android above 9.0, the kernel defaults to have an eBPF framework and is directly used for head-to-tail instrumentation function expansion of key functions;

for a low-version linux/android operating system, performing function expansion on head-to-tail instrumentation of a key function by using a kernel default self-contained kprobe/uprobe;

for windows and IOS operating systems, the function extension is done using the front-to-back instrumentation of the hook framework key functions of the frida maturity.

The invention has the following advantages: a stack overflow automatic defending method based on key address dynamic protection limits stack memory attribute of a function return address to be read-only, any attack method cannot tamper the function return address, successfully defends attack modes of return2shellcode, and only jumps to a preset teller function address when a retn instruction is executed after the function is finished, and successfully defends attack modes of return2 libc.

Drawings

FIG. 1 is a flow chart of a conventional __ stack_chk_guard method;

FIG. 2 is a schematic flow chart of the DEP mode in the prior art;

FIG. 3 is a schematic flow chart of the ASLR method;

FIG. 4 is a code schematic of a mainstream compiler function when compiling code;

FIG. 5 is a diagram of the stack space of a function of a callle when the instruction is executed according to the present invention, shown in FIG. 1;

FIG. 6 is a diagram of the stack space of the function of the impeller when the instruction is executed according to the present invention;

FIG. 7 is a flow diagram of stack overflow defense according to the present invention;

FIG. 8 is a schematic diagram of the analysis of a read function;

fig. 9 is a schematic diagram of an address mapping of libc library functions in virtual memory.

Detailed Description

For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application, which are generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Accordingly, the following detailed description of the embodiments of the present application, provided in connection with the accompanying drawings, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, are intended to be within the scope of the present application. The invention is further described below with reference to the accompanying drawings.

The invention particularly relates to an automatic stack overflow defending method based on dynamic protection of a key address, which defends stack overflow attack by inserting piles from the head to the tail of kernel mode and user mode functions by means of common pile inserting tools such as eBPF helper/kprobe/upper hook frames and the like.

Taking the x86 architecture as an example, as shown in fig. 4, the head-to-tail fixing of functions when compiling source code by the mainstream compiler is as follows:

as shown in fig. 5, after the completion of the execution of the calle, in order to return to the execution of the calle code correctly, after the calle executes a call instruction, the ebp register value of the original calle needs to be stacked and stored in the calle function, and the corresponding code is "push ebp". When executed inside the pellee function, in order to correctly address the incoming parameters and local variables within the time complexity of O (1), the ebp register value of the pellee needs to be pointed to the bottom of the stack, with the corresponding code "movebp, esp".

As can be seen from fig. 5, there are no local variables on the function stack of the calle because no assignment instruction has yet been executed, and the entire stack is now secure. In order to prevent the return address of the function from being tampered by the subsequently executed local variable assignment code, a pile needs to be inserted at the next instruction of 'movebp, esp', the memory attribute at ebp+4 is changed to be read-only, and then the original function is jumped back to continue to execute. Once the local variable assignment instruction attempts to modify the data of the memory block, the MMU (memory manager) immediately detects the illegal operation, then generates a system interrupt to inform the CPU of the processing exception, and the whole original program stops executing, so that any subsequent local variable assignment instruction cannot change the value of the memory address of the block, thereby protecting the accuracy of the return address after the completion of the execution of the impeller.

After all instructions of the Callee function are executed, the instructions need to be continued to be executed by jumping back to the caller function through the retn instruction, as shown in fig. 6. In order to ensure smooth continuation after the return from the calee to the caller function, the caller function needs to restore the stack space of the caller function before the retn is executed, otherwise, the caller function cannot address the local variables in the stack, and the corresponding code is 'movest, ebp', which is logically just opposite to the beginning of the function.

The function is dynamically inserted after 'movebp, map', the return address of the function is set to be read-only, the return address is protected from being maliciously tampered by local variables, but the execution of the function is finished when retn, the function is inserted at retn, the stack memory attribute for storing the return address is changed into readable and writable and then released, and the error reporting caused by non-writable when other functions normally use the stack memory at the position is avoided.

As shown in FIG. 7, upon initial execution of the function, instrumentation is performed at the third line of code, setting the memory attribute at ebp+4, i.e., the return address, to read-only. At the moment, the code of the local variable assignment is not executed, so that the memory attribute can be protected from being tampered maliciously after being read only; when the function is executed, i.e. the retn statement is to be executed, the code assigned by the local variable is already executed, so that the heap is inserted, the attribute of the stack memory pointed by the esp (i.e. the memory for storing the return address) is changed into readable and writable, and the exception when other functions call the stack.

Automatic addressing of pile placement:

in the whole software system, most functions are used for realizing the internal functions of the system, and the functions cannot interact with external users or accept data input by the external users, so that a compiler can statically check whether assignment of local variables is out of range or not during compiling of the functions, and stack overflow protection is not required to be dynamically performed. Conversely, only a small number of functions need to receive external user input, and these function stacks are high risk areas and need to do dynamic stack overflow defense, so that functions that need to receive data from a user and frequently interact with the user, including but not limited to functions such as open, read, write, cin, cout, getchar, send, sendto, receive, receivefrom, prinft (hereinafter referred to as "interaction functions"), can be selected in a user mode or a kernel mode. The entry addresses of these interactive functions can be obtained by parsing the dynsym segment of the file header, and can be obtained directly by the readelf command under linux, taking the read function as an example.

As shown in fig. 8, the 3 rd and last columns are the entry address and function name of the function, respectively, by which the relative entry address offset of the interactive function can be quickly obtained. For example, the read function is a high risk function of stack overflow with an entry address offset from the libc base address of 0xefc60. The machine code corresponding to the assembler instruction 'movebp' and the map 'is' 0x89 x 0xE5 ', and the assembler instruction' movebp 'and the map' can be sequentially searched from the beginning of the entry 0xefc60 of the read function directly until the first '0 x89 x 0 xE5' machine code is searched, and the position of the next byte can be used for dynamic instrumentation. Similarly, the machine code corresponding to the retn instruction is 0xC3, and can be sequentially searched from the entry address of the read function, and dynamic instrumentation is performed on the position of each searched 0xC3 machine code.

The readelf command can search offset of the high-risk interaction function entry relative to the library function, but cannot accurately acquire the loading address of the memory of the library function, so that the absolute virtual address of the high-risk interaction function cannot be acquired only by means of the readelf command, and the address mapping of all library functions in the memory needs to be checked further.

The Linux system adopts the idea of 'everything is file', stores all important data in the file, wherein the mapping of the loaded library function in the virtual memory address is also included, and the mapping is stored in the/proc/pid/map file. And randomly selecting the pid of a user-state process through a top command, and checking the address mapping of a libc function in a virtual memory in the process through a command of 'cat/proc/pid/maps|grep libc'.

As shown in fig. 9, from the above graph, it can be seen that the base address of the libc.so library function is 0x7fdd208cd000, and the offset of the read function compared to the libc.so library function is 0xefc60, so that it can be determined that the absolute virtual address of the read function in the memory is libc.so library function base address+read function offset=0x7fddd208cd000+0xefc60=0x7fd209 bcc60. The searching of all pile inserting points can be realized through program automation, and no manual intervention is needed in the whole process.

The frame selection of the stake includes: for high-version operating systems with the linux above 3.18 and the android above 9.0, the kernel defaults to have an eBPF framework and is directly used for head-to-tail instrumentation function expansion of key functions; for a low-version linux/android operating system, performing function expansion on head-to-tail instrumentation of a key function by using a kernel default self-contained kprobe/uprobe; for windows and IOS operating systems, the function extension is done using the front-to-back instrumentation of the hook framework key functions of the frida maturity.

The invention utilizes the modified memory attribute to achieve the purposes of protecting the return function address on the stack and preventing stack overflow, but is not limited to stack overflow protection, and can be applied to the stack overflow protection: APP safety protection: by setting read-only and executable attributes for the memory storing the key codes, the method can prevent malicious hook, dynamic debugging and cracking of a third party, and achieves the purposes of anti-debugging and anti-hook.

The foregoing is merely a preferred embodiment of the invention, and it is to be understood that the invention is not limited to the form disclosed herein but is not to be construed as excluding other embodiments, but is capable of numerous other combinations, modifications and environments and is capable of modifications within the scope of the inventive concept, either as taught or as a matter of routine skill or knowledge in the relevant art. And that modifications and variations which do not depart from the spirit and scope of the invention are intended to be within the scope of the appended claims.

Claims (6)

1. A stack overflow automatic defending method based on key address dynamic protection is characterized in that: the stack overflow automatic defense method comprises the following steps:

after the execution of the pellee function is finished, executing a first instruction to enable an ebp register of the original peller to be implanted into stack protection in the inner part of the pellee function, executing a second instruction to enable an ebp register value of the pellee to point to the stack bottom, enabling an incoming parameter and a local variable to be correctly addressed when the inner part of the pellee function is executed, inserting piles at the position of the next instruction of the second instruction to prevent the return address of the function from being tampered by a local variable assignment code executed later, and detecting through a memory manager;

and executing the third instruction to restore the stack space of the function, ensuring that the function addresses local variables in the stack, inserting piles at the return instruction, changing the stack memory attribute storing the return address into the second state, and then executing the return instruction to jump back to the function to continue execution, thereby ensuring smooth continuation of the return function.

2. The automatic stack overflow defense method based on dynamic protection of key addresses according to claim 1, wherein: the instrumentation at the next instruction of the second instruction prevents the return address of the function from being tampered by the subsequently executed local variable assignment code, and the detecting by the memory manager includes:

inserting piles at the next instruction of the second instruction, changing the memory attribute at the ebp+4 position into a first state, then jumping back to the original function to continue execution, once the memory block of the ebp+4 is modified by the instruction with the local variable assignment, immediately detecting the illegal operation by the memory manager, sending an interrupt notification CPU to process the exception, stopping the whole original program execution, enabling the subsequent assignment instruction of any local variable not to change the memory address value of the memory block, and protecting the accuracy of the return address after the completion of the execution of the calee.

3. The automatic stack overflow defense method based on dynamic protection of key addresses according to claim 1, wherein: the first state is a read-only state, the second state is a readable and writable state, and the memory occupied data for storing the return address is released after being changed into the readable and writable state, so that error reporting caused by non-writable state when other functions normally use the memory occupied here is avoided.

4. A stack overflow automatic defense method based on dynamic protection of key addresses according to any one of claims 1-3, characterized in that: the stack overflow automatic defending method further comprises a pile inserting position automatic addressing step, wherein the pile inserting position automatic addressing step comprises the following steps:

acquiring an interactive function which needs to receive data from a user and is frequently interacted with the user in a user mode or a kernel mode, and acquiring an entry address and a function name of the interactive function by analyzing a file header;

calculating and obtaining the offset of the interactive function entry address relative to the libc library function base address, sequentially searching from the offset until the first and second instructions are found, calculating the absolute virtual address required by instrumentation, and dynamically instrumentation is carried out at the position of the next byte of the second instruction.

5. The automatic stack overflow defense method based on dynamic protection of key addresses according to claim 4, wherein: the absolute virtual address needed by the calculation pile comprises the following specific contents:

and searching offset of an entry address of the interactive function relative to the libc library function through an instruction, randomly selecting a pid of a user state process through a top instruction, checking the address mapping of the libc library function in a virtual memory in the process, obtaining the base address of the libc library function, and obtaining the absolute virtual address of the interactive function in the memory through the offset and the base address of the libc library function.

6. The automatic stack overflow defense method based on dynamic protection of key addresses according to claim 4, wherein: the frame selection of the stake includes:

for high-version operating systems with the linux above 3.18 and the android above 9.0, the kernel defaults to have an eBPF framework and is directly used for head-to-tail instrumentation function expansion of key functions;

for a low-version linux/android operating system, performing function expansion on head-to-tail instrumentation of a key function by using a kernel default self-contained kprobe/uprobe;

for windows and IOS operating systems, the function extension is done using the front-to-back instrumentation of the hook framework key functions of the frida maturity.

Images