Four protection methods for Buffer Overflow

Currently, there are four basic methods to protect the buffer zone from attacks and impacts caused by buffer overflow.
I. Write the correct code
Writing the correct code is a very meaningful but time-consuming task, especially a program that is prone to errors (such as the zero-end character string) written in C language ), this style is caused by the pursuit of performance and ignoring the correctness of the tradition. Although it took a long time to let people know how to write secure program groups with security vulnerabilities, the program still appeared. Therefore, some tools and technologies have been developed to help experienced programmers write secure and correct programs.
The simplest method is to use grep to search for vulnerable library calls in the source code. For example, the call to strcpy and sprintf does not check the length of input parameters. In fact, the standard library of each version C has such a problem. To find some common vulnerabilities, such as buffer overflow and operating system competition conditions, some code check teams have checked a lot of code. However, there are still some fish that have missed the internet. Although the substitution functions strcpy and sprintf are used to prevent buffer overflow, this still happens due to code writing. For example, the lprm program is the best example. Although it passes the code security check, there is still a buffer overflow problem.
To solve these problems, some advanced error checking tools, such as faultinjection, were developed. These tools are designed to search for code security vulnerabilities by manually generating random Buffer Overflow. There are also some static analysis tools used to detect the existence of buffer overflow. Although these tools can help programmers develop safer programs, due to the characteristics of the C language, these tools cannot find all the buffer overflow vulnerabilities. Therefore, the error detection technology can only be used to reduce the possibility of buffer overflow, and cannot completely eliminate its existence, unless the programmer can ensure that his program is worth RMB 1 million.
| 2. Non-execution Buffer
　　
By making the data segment and address space of the attacked program unexecutable, attackers cannot execute the code implanted into the buffer entered by the attacked program. This technology is called the non-execution Buffer technology. In fact, many old Unix systems are designed like this, but recently Unix and MS Windows systems tend to dynamically release executable code in data segments to achieve better performance and functionality. Therefore, to maintain program compatibility, it is impossible to make the data segments of all programs unexecutable. However, we can set the stack data segment to be unexecutable, so as to maximize program compatibility. Linux and Solaris have released Kernel patches in this regard. Because almost no program can store code in the stack, this practice almost does not produce any compatibility issues, except for the two special cases in Linux, the executable code must be put into the stack:
1. Signal Transmission
In Linux, the code in the stack is executed by releasing code to the process stack and causing interruption, so as to send Unix signals to the process. unexecuted buffer patches allow the buffer zone to be executed when sending signals.
2. Online reuse of GCC
The study found that gcc placed executable code in the stack area for online reuse. However, disabling this function does not cause any problems. Only some functions seem to be unavailable. The protection of non-execution stacks can effectively deal with buffer overflow attacks that Implant code into automatic variables, but it is ineffective for other forms of attacks. You can skip this protection by referencing the pointer of a resident program. Other attacks can bypass protection by embedding code in heap or static data segments.
3. array boundary check
Buffer overflow caused by code implantation is one aspect, and disturbing the program execution process is another aspect. Unlike non-execution buffer protection, the array boundary check does not have any buffer overflow and attacks. In this way, as long as the array cannot be exceeded, the overflow attack will be impossible. To implement array boundary check, all read/write operations on the array should be checked to ensure that the operations on the array are within the correct range. The most direct method is to check all Array Operations, but some optimization techniques can be used to reduce the number of checks. Currently, the following methods are available:
1. Compaq C Compiler
The C compiler developed by Compaq for Alpha CPU supports limited boundary checks (using the-check_bounds parameter ). These restrictions are: only the displayed array reference is checked. For example, "a [3]" will be checked, while "* (a + 3)" will not. Since all the C arrays are transmitted by pointers, the arrays passed to the function are not checked. Risky library functions such as strcpy do not perform boundary checks during compilation, even if boundary checks are specified. In C language, it is very frequent to use pointers for Array Operations and transmission. Therefore, this limitation is very serious. Generally, this kind of boundary check is used for program error detection, and it cannot be guaranteed that there will be no buffer overflow vulnerability.
| 2. array boundary check for Jones & Kelly: C
　　
Richard Jones and Paul Kelly developed a gcc patch to fully check the array boundary of the C program. The compiled program has good compatibility with other gcc modules because it does not change the pointer meaning. Furthermore, they export a "base" pointer from an expression without a pointer, and then check the base pointer to detect whether the expression results are within the permitted range. Of course, the performance cost is huge: for a program that frequently uses pointers, such as vector multiplication, the speed will be slowed by 30 times due to frequent usage of pointers. This compiler is not yet mature, and some complex programs (such as elm) cannot be compiled or executed on it. However, in an updated version, it can compile and execute at least the encryption software package of the ssh software, but its implementation performance will be reduced by 12 times.
3. Purify: memory access check
Purify is a tool used to view memory during debugging of C Programs, rather than a dedicated Security Tool. Purify uses the "target code insertion" technology to check all memory access. By using the Purify Connection Tool, the performance loss caused by executable code execution is 3-5 times lower.
4. Type-Security Language
All buffer overflow vulnerabilities are caused by C language security. If only the type-safe operation can be performed, it is impossible to force the operation on the variable. If you are a newbie, we recommend that you use a type-safe language such as JAVA and ML.
However, the Java Virtual Machine, as a Java execution platform, is a C program. Therefore, one way to attack JVM is to overflow the JVM buffer. Therefore, using the buffer overflow Defense Technology in the system to use the forced type-safe language can receive unexpected results.
Iv. Program pointer integrity check
The program pointer integrity check is slightly different from the boundary check. Unlike preventing program pointer changes, the program pointer integrity check detects changes before the program pointer is referenced. Therefore, even if an attacker successfully changes the pointer of the program, the pointer will not be used because the system detects the pointer change in advance. Compared with array boundary check, this method cannot solve all buffer overflow problems. Other Buffer Overflow methods can be used to avoid this detection. However, this method has great advantages in performance and compatibility.
L handwritten stack monitoring
Snarskii is a set of customized libc for FreeBSD developers that can monitor the cpu stack to determine Buffer Overflow. This application is completely written by means of manual compilation and only protects the current valid record function in libc. this application meets the design requirements and provides good defense for libc library function-based attacks, but cannot defend against other attacks.
| 2. stack protection
　　
Stack protection is a compiler technology that provides program pointer integrity check. It is implemented by checking the return address in the function activity record. Stack protection is a small patch of gcc. In each function, code for function creation and destruction is added. The added function creation Code adds some additional bytes to the return address of the function in the stack. When the function returns, first check whether the added byte has been changed. If a buffer overflow attack occurs, this attack can be easily detected before the function returns. However, If attackers anticipate the existence of these additional bytes and can create them in the same way during the overflow process, they can successfully skip the detection of stack protection. Generally, we have two solutions to deal with such spoofing:
1. Terminator
Termination symbols such as o (null, CR, LF,-1 (Eof) in C language cannot be used in common string functions, because once these termination symbols are met, these functions end the function process.
2. random symbols
A 32-bit random number generated during function calling is used for confidentiality, making it impossible for attackers to guess the content of additional bytes. in addition, the content of each call to append byte is changing and cannot be predicted. The stack protection law that checks the integrity of the stack evolved from the Synthetix method. The Synthetix method uses quasi-constants to ensure the correctness of specific variables. The changes to these specific variables are predictable for the program implementation and can be changed only when certain conditions are met. Such variables are called quasi-constants. Synthetix has developed some tools to protect these variables. Changes caused by buffer overflow can be taken as illegal actions by the system. In some extreme cases, these quasi-constants may be illegally changed. In this case, stack protection is required to provide better protection. The experimental data shows that stack protection can effectively protect various system buffer overflow attacks and maintain good compatibility and system performance. Analysis shows that stack protection can effectively defend against current and future stack-based attacks. The stack protection version of Red Hat Linux 5.1 has been running on a variety of systems for many years, including personal laptops and workgroup file servers.
3. pointer Protection
During the design of stack protection, the impact stack constitutes a common form of buffer overflow attacks. Some people speculate that there was a template for these attacks (in 1996 ). Since then, many simple vulnerabilities have been discovered. After implementation and patches, many attackers have begun to use more general methods to implement buffer overflow attacks. Pointer protection is a promotion of heap money protection in this case. By placing additional bytes after all the code pointers, we can check the validity of the pointer before it is called. If the test fails, an alarm is sent and the program is exited, just like the action in stack protection. Note the following two points for this solution:
(1) Location of additional bytes
The space of the additional bytes is allocated when the protected variable is allocated and initialized during the initialization of the protected byte. This poses a problem: to maintain compatibility, we do not want to change the size of protected variables, so we cannot simply add additional words to the variable's structure definition. Also, different types of additional bytes are available.
(2) query additional bytes
Each time the program pointer is referenced, the integrity of the additional bytes must be checked. This also has a problem because "read from accessors" does not have semantics in the compiler. the compiler is more concerned with pointer usage, and various optimization algorithms tend to read human variables from memory. the reading methods vary with the variable types. So far, only a few-some attacks using non-pointer variables can escape pointer protection detection. However, you can add additional bytes to a variable in the compiler to implement detection. In this case, the programmer needs to manually add corresponding protection.

Currently, there are four basic methods to protect the buffer zone from buffer overflow.