1. Background
Applications developed by C/C++ have long had security problems of memory corruption. After the attacker has mastered the vulnerability of the target program, he can develop a vulnerability exploit program to hijack the control flow of the target program. Early exploits used code injection, by placing a piece of code (shellcode) in the buffer, and then controlling the pc register to jump into the buffer to execute this code. In order to prevent such attacks, the computer system deployed the DEP (Data
Execution
Prevention) mechanism later. By configuring the memory page attributes, the buffer was set to be non-executable, which played a very good defense effect. In order to bypass DEP, the attacker explored the code reuse technology, searched for some code fragments of the attacker's expected operation in the target program, and finally realized the control of the target machine by organizing these fragments. Such attack techniques include Return-
to-libc, ROP (Return Oriented Programming), JOP (Jump
Oriented Programming), etc. As shown in the figure below, the code has two dynamic paths, and there is a node with a vulnerability in path 1. When an attacker modifies the jump logic of this node through a vulnerability, if there is no reliable legality verification mechanism, the attacker can finally completely control the target machine.
In order to defend against the above code reuse attacks, the University of California and Microsoft proposed a Control-Flow-Integrity ( CFI) defense mechanism in 2005 . Control-Flow-Integrity (CFI)
is a security policy that ensures that software must execute on a previously determined control flow graph. Its core idea is to verify the legitimacy of the jump when an uncertain jump occurs in the function.
CFI is divided into Forward Edges CFI and Backward Edges
CFI. The former is to verify the control flow before the indirect call, while the latter is to verify whether the return address belongs to the caller when the function returns. The relevant implementations under Linux are listed below, as follows:
Currently, there is also Backward CFI implemented by hardware
-
Intel CET hardware-based read-only shadow call stack
-
ARM V8.3a Pointer Authentication(“signed return address”)
##二、struct sanitizer
By analyzing some common kernel vulnerability POCs, we found that the modification of the control flow of these POCs is concentrated on the modification of the built-in function pointers of several structures. However, the above CFI solution requires instrumentation to verify the control flow of all codes, which will inevitably lead to obvious performance degradation. So we propose struct-
sanitizer (struct_san), a new control flow integrity detection mechanism.
Compared with the above CFI scheme, struct_san is more stringent in verifying the structure pointer than the existing CFI technology. The current mainstream CFI technology mainly verifies the type of the function pointer, and struct_san also verifies whether the function pointer still belongs to the current structure instance on this basis. struct_san can also implement non-full amount of piles to reduce some non-unnecessary performance loss.
## Three, the implementation principle
struct_san works as follows:
struct san
verifies whether the function pointer belongs to the current structure instance by adding the verification function __sanitizer_struct_guard__() before calling the function in the structure. If the verification is valid, continue to run the following indirect call function, otherwise throw ud2.
## 4. How to use
struct_san In order to avoid partial instrumentation, a new GNU Attributes attribute ((sanitize_struct)) is added.
The method of use is to add this keyword before the declaration of the structure type that you want to protect and the function that calls the function pointer of this structure, for example, you want to protect the pipe_buf_operations->release() function in the pipe_buf_release() code in the kernel.
1. Add this keyword when declaring the structure type
After the type declaration is completed, struct_san will save all structure instances of this type to the .sanitize_struct segment.
2. Add the above keywords to the functions that need to be protected. For example, add keywords to the declaration and definition of the pipe_buf_release() function. After adding keywords, the verification function __sanitizer_struct_guard__() will be inserted before calling pipe_buf_operations->release()
The following are the different representations in gcc's gimple IR before and after piling:
Before piling
After piling
## Five, detection algorithm
struct_san is currently only implemented in the kernel. The algorithm is to create a 128M shadow memory in the kernel
to save the corresponding relationship between the structure and the structure pointer. When sanitizer_struct_guard () is called, it will detect whether the incoming struct and function pointer are in the shadow
memory. If not, a ud2 exception will be thrown, otherwise the function pointer will be returned. The implementation plan is as follows:
This algorithm refers to the implementation of AddressSanitizer, taking into account both effect and efficiency.
## Six, the effect
Taking the attack code of the vulnerability CVE-2021-22555 as an example, when struct_san is enabled, CFI blocks the execution of the attack code and plays an effective defense.
at last
For students who have never been exposed to network security, we have prepared a detailed learning and growth roadmap for you. It can be said that it is the most scientific and systematic learning route, and it is no problem for everyone to follow this general direction.
At the same time, there are supporting videos for each section corresponding to the growth route:
Of course, in addition to supporting videos, various documents, books, materials & tools have been sorted out for you, and they have been classified into categories for you.
Due to the limited space, only part of the information is displayed. Friends in need can [click the card below] to get it for free: