Use the/GS switch in VC ++ to prevent Buffer Overflow

Buffer overflow is usually manifested as the most common vulnerability that exists in today's various software. Hackers can use malicious input to change the program execution process, the intrusion into the corresponding process, computer, or whole domain. If a process runs under a highly trusted account, such as an administrator or a local system account, the damage caused by hackers is extremely serious and potentially spreading widely. In recent years, some well-known viruses, such as the red code, shock wave, and shock wave, all originate from the buffer overflow of C/C ++ code.

From the perspective of the program, buffer overflow is just a simple programming error -- it is about copying the content of one memory area to another memory area, and the size of the target memory area is too small to accommodate. The following code is a simple demonstration:

Char * source = "A reasonably long string "; Char dest [10]; : Strcpy (dest, source );

In this example, the source string is 25 characters long (including an empty Terminator), which is undoubtedly too large for the target memory block, the target memory block is declared on the stack. When this code is executed, the original stack will be destroyed and the program will crash due to an access violation. If the source memory block is provided by an external third party, a vulnerability may exist because it allows the memory block of the Input Function to modify the stack in a specific way.

When a function is called in C/C ++, the return address of the called function is stored in the stack. Therefore, when the called function is executed, the execution process can be returned to the original site again. If you call a function that may contain potential buffer overflow, the return address may be modified and the execution process will jump to the specified place in the buffer data. By changing the return address of the function, attackers can obtain code from any location in the process for execution. Generally, the code can be exploited in two ways:

· If programs with vulnerabilities are known and accessible, attackers can find the address of a function, which is usually found at a fixed address of all process instances; and modify the stack, waiting for this function to be called.

· The commands to be executed can be transmitted to the process address space as part of the buffer zone. Attackers can exploit this to complete the attack.

　Prevent Buffer Overflow

The simplest way to prevent buffer overflow is to limit the size of the copied data so that it cannot exceed the target buffer capacity. Although this method seems insignificant, In fact, experience has proved that it is a very difficult task to completely eliminate the hidden danger of buffer overflow in those large C/C ++ code. In addition, such. managed technologies such as NET or Java can also greatly reduce the risk of buffer overflow, but it is unlikely or inappropriate to port large projects to this technology.

Stack-based buffer overflow can be easily exploited because the instruction generated by the compiler stores the return address of the function in the stack, only plays one small role. From Visual C ++. starting from NET (7.0), the Visual C ++ development team adopted a method to reduce the probability of such problems from the compiler aspect, they store the data of the function return address in the stack and insert a cookie with a known value. Therefore, if the buffer overflow changes the return address value of the function, this cookie will also be overwritten. When the function returns, the cookie is usually detected. If the cookie is detected to have been modified, a security exception will be thrown, if the exception is not handled, the process will be terminated. The following code demonstrates a simple program with a security exception handling method:

Void _ cdecl sec_handler (int code, void *) { If (code = _ SECERR_BUFFER_OVERRUN) { Printf ("a buffer overflow is detected. /N "); Exit (1 ); } } Int main () { _ Set_security_error_handler (sec_handler ); // The main program code is omitted here. }

Visual C ++. NET 2003 (7.1) moves the vulnerable data structure (such as the address of the exception handling method) to a location under the buffer in the stack, enhanced the protection of buffer overflow. In compiler 7.0, attackers can bypass the protection provided by secure cookies by damaging sensitive data between the buffer and cookie. However, in the new version of compiler, the data has been moved to an area under the buffer zone. It seems impossible to modify the data to overflow.

Figure 1 demonstrates the stack concept layout in C ++ compilers 6, 7.0, and 7.1, and shows the stack growth from high address to low address space, this is also the direction of stack growth when the program is executed. Stack growth is the main cause of buffer overflow, because overflow will be overwritten in the memory address space higher than the buffer, and this is the place where vulnerable data structures reside.

Figure 1 logical STACK layout

In addition to moving the exception handling method and other information to the data buffer in the stack, the Visual C ++. NET 2003 linker also places the address of the structured exception handling method to the header of the executable file. When an exception occurs, the operating system can check the exception information address in the stack to determine whether the exception handling method recorded in the file header information is correct. If the exception does not match, the exception handling method will not be executed. For example, Windows Server 2003 can check the structured exception information, and this technology is also transplanted to Windows XP in Service Pack 2.

Visual C ++ 2005 (8.0) takes another step. When a function call occurs, if one of the Local Buffers exceeds the limit, attackers may rewrite anything on the top of the stack, including Exception Handling, secure cookies, frame pointers, return addresses, and function parameters. Most of these values are protected by different mechanisms (such as security exception handling), but for a function with function pointers as parameters, there is still a chance of overflow. If a function accepts a function pointer (or a structure or class contains a function pointer) as a parameter, attackers may rewrite the value in the pointer to execute any function they want. In view of this, the Visual C ++ 2005 compiler will analyze all function parameters that may have this vulnerability and copy a function parameter -- without using the original function parameters, place it under the local variable in the stack. If the original function parameter is overwritten, the entire function will not be cracked as long as the value in the copy remains unchanged.
　　Application Buffer Protection

You can enable buffer protection by simply enabling the/GS compiler switch. In Visual Studio, this switch can be found in the "Code Generation" option on the "C/C ++" option page (2 ). By default, it is disabled in Debug configuration, and enabled in Release configuration.

Figure 2: Set/GS Switch

If you use the latest version of the compiler to compile and generate structured exception information, the security structured exception processing is enabled by default. In addition, you can also use/SAFESEH: the NO command line option is used to disable security structured exception handling. in Visual Studio Project Settings, security structured exception handling cannot be disabled, however, you can still use this command line option in the linker.

　　/GS and further security prospects

Simply turning on a compiler switch won't completely secure a program, but today when security vulnerabilities appear in various forms, it will help to make the program more secure. Stack-based buffer overflow is a major type of security vulnerabilities. However, with the continuous update of hacker attack technologies, there is still a long way to go.

In Microsoft's formal terminology, both/GS and SAGESEH are software-forced Data Execution Protection (DEP), and software-forced DEP can also be implemented in hardware mode, for example, if the data appears on the memory page marked as "unexecutable" in the CPU that implements this function, it will not be executed. Windows XP SP2 and Windows Server 2003 now support these technologies. Currently, most 32-bit CPUs and all 64-bit CPUs on the market support security enhancement technologies such as No Execute (NX.

Any good security system has multiple levels of preventive measures to address security threats. The compiler switch involved in this article can prevent or reduce the security risks caused by common coding errors, and it is easy to use and low cost. In this war without smoke, it is a good solution. It is definitely worth using your program.