[Translation] UseGS option switch to prevent buffers overflow vulnerability

xiaoxiao2021-03-06  75

Switch to prevent buffers overflow vulnerability with / GS option

Author: Nick Wienholt

October 6, 2004

Translator: Wu Xiuxiang

10.8.2004

(Note: Source text: http://www.codeguru.com/columns/kate/Article.php/c8361/)

Buffer overflow is one of the most common security hazards that exists in software. By providing a malicious input hacker to change the execution process of the process, the buffer overflow can threaten the entire process, machine, or even related system. If the running process is below the user, such as Administrator or a local system account (Local System Account), the loss caused by hackers will be very serious and will face a broader potential critical. Some well-known viral images, red code viruses, and oscillating worms, which have been exploded in the nearest period, are the result of buffer overflow in C / C code.

Buffer overflow is a simple programming error - is that people are too small in the target area space when copying data from a memory area, and the target area space is too small without placing down these source data. The following code demonstrates a small example.

Char * source = "a reasonably long string";

Char DEST [10];

:: STRCPY (DEST, SOURCE);

In this example, the source string has 25 characters long (including a NULL ending), which will appear too long for the target memory block defined in the stack. When this code is executed, the stack will become confusing, and usually the program will access violations and cause crash. If the source memory block is provided from the outside, there will be a security hidden danger, as this makes people can use this memory block to pass through some way to the function memory.

In C / C When the modulation function is called, the return address of the function is stored inside the stack, so it will return to this address when the modified function is executed. When a function of a potential buffer overflows is called, the return address may be modified, and the execution process will jump to the location of the data specified by the buffer. By modifying the return address of the function, an attacker can perform code in any location in the process. This adopts two aspects:

1. If this defective application is widely used, the attacker can find a function that has a fixed address in all process instances and then modifies the stack to call this function.

2. If the execution instruction can be used as part of the buffer, the address space of the process can be passed, then this attacker can use this to achieve an attack.

Prevent buffer overflow

The simplest preventive measures are to limit the length of the copied data so that he will not be larger than the length of the target memory block. Applying this measure looks like it is insignificant. In fact, he depends on people's attitude, just as early as the example - Experience shows the potential buffer overflow vulnerability of the program based on C / C code program. The task of almost impossible to complete. It is positively to reduce potential overflow vulnerabilities with drag technology, like .NET and Java. But it is often impossible or inappropriate to migrate countless code to this technology. >

The reason why the stack-based buffer overflow vulnerability is to be utilized is that the return address of the function is saved in the stack through the instruction generated by the compiler. Recognizing this, the compiler also plays a certain role in this vulnerability, and the Visua C team has recently eased this problem properly on Visual C . Net (7.0). They are inserted in advance, in advance, in advance, in advance, in advance, in the stack. By using this technology, a buffer overflow problem, change the function to return to the registration, the same, it will also overwrite this value. This value is required to be detected when returning. When a modification is detected, a secure exception will be thrown. If this exception is not processed, the process will exit, the following code demonstrates a backbone with a safe exception handler: void _cdecl sec_handler (int Code) , void *)

{

IF (code == _secerr_buffer_overrun)

{

Printf ("You Had A Buffer Overrun / N);

Exit (1);

}

}

int main ()

{

_SET_SECURITY_ERROR_HANDLER (SEC_HANDLER);

// main Application Code Here

}

Visual C .NET 2003 (7.1) By moving vulnerable data structures, such as an unusual handler address, to the buffer of the stack to enhance the exploit capability of the buffer overflow. In a 7.0 version of the compiler, by changing sensitive data between buffers and security values ​​can bypass the protection provided by the security value mechanism. However, the new version of the compilement is impossible to modify these data by moving these numbers to the buffer.

Figure 1: Logical Stack Layout

In addition to moving exception processing information to the stack of data buffers, Visual C . Net2003 connector simultaneously places all structured exception handler addresses to the header of the execution file. When an exception occurs, the operating system can find an exception handler stored in the stack exception processing information and record in the execution file header information. If this is not the case, the exception handler will not be executed. Windows Server2003 integrates the ability to detect structural exception information, and this technology has recently been applied to Windows XP SP2.

Use buffer protection

Open (activation) buffer protection is relatively simple, as long as you open the compiler / GS switch. Using Visual Studio, this switch can be activated in the following way: Code Generation Option Page in the C / C page. By default, this setting is closed in the release configuration in the release configuration.

Safety structured exception handling default, if all programs are compiled and generated using the most recent edcharier and generate structured exception information, the target subsystem is information. The Windows CE operating system does not use security structured exception handling information, and the word will not be included if the target system is not required. / SAFESEH: No command line switch can be used to turn off structural exception handling. There is no setting option for security structured exception processing in Visual Studio Project-Setting, but it can close this option by command line options to connect to this Visual Studio project.

/ GS and a wide range of security issues

An annoying compilation switch does not make an application security. It can only make this program more secure, but the security hidden dangers come from different forms. A stack buffer overflow is an important security hazard, and the technique for hackers is used to attack programs far more than this. Although the initial relative look is harmless, the stack buffer overflow is becoming a known hidden danger, and there are other attacks: SQL INJECTION (SQL statement injection), cross-site scripting, and refusal service can benefit from The security check of / GS option. In order to use this technique, / GS, and Safeseh that is used by Microsoft, software-enhanced data execution protection (DEP). Hardware - Strengthening DEP is also supplemented with software-strengthening DEP. If a page is marked as NO-EXECUTABLE (cannot be performed), the processor will reject execution instructions. These technologies are currently supported by Windows XP SP2 and Windows Server 2003, but other processors do not support this tag. AMD and Intel are highly supported in the 64-bit machine, and the 32-bit processor in the future may add support for this security technology.

Any good security system has multiple layers of prevention mechanisms to deal with some destroyers. Compiler assist, prevent or reduce general coding error hazards, can participate in this prevention as a layer of mechanism. Through this easy-to-use and low cost prevention, it is worthwhile to use in the application.

转载请注明原文地址:https://www.9cbs.com/read-109581.html

New Post(0)