Visual C++: Protecting Against Buffer Overruns with the /GS Switch, Page 2
Using Buffer Protection
Activating buffer protection is a simple matter of turning on the /GS compiler switch. Using Visual Studio, the switch can be activated from the Code Generation option page on the C/C++ tab (as shown in Figure 2). By default, the setting will be disabled for the Debug configuration and enabled for the Release configuration.
Figure 2: Setting the /GS Switch
Safe structured exception handling will be enabled by default if all the inputs to the linker, where compiled with the most recent version of the compiler and producing the structured exception information, makes sense for the target subsystem. The Windows CE operating system does not make use of the safe structured exception handling information, and it will not be included if this operating system is targeted. The /SAFESEH:NO command line switch can be used to disable safe structured exception handling. There is no Visual Studio project-setting item to disable safe structured exception handling, but it can be done for a Visual Studio project using the command line options for the linker.
/GS and the Wider Security Picture
Flipping a single compiler switch will not make an application secure. It can help make an application more secure, but security vulnerabilities come in many different forms. Overruns of stack-based buffers are an important class of security vulnerability, but they are far from the end of the story when it comes to the techniques that hackers will use to attack an application. Despite initially appearing relatively harmless, heap-based buffer overruns are now known to be an exploitable vulnerability, and other attacks like SQL injection, cross-site scripting, and Denial of Service can all happily succeed against an application that relies on /GS for security.
To use the formal terminology that has been adopted by Microsoft, /GS and SAFESEH are examples of software-enforced data execution prevention (DEP). Software-enforced DEP also can be complemented by hardware-enforced DEP, in which the processor will refuse to execute instructions if they are located within a memory page that has been marked as non-executable. Windows XP SP2 and Windows Server 2003 currently support these technologies, but few shipping processors have No Execute (NX) support. AMD and Intel have high-end offerings in the 64-bit world with NX technology, and future 32-bit processors may also ship with these security enhancements.
Any good security system has multiple layers of defense to defeat the bad guys. Compiler assistance, which can defeat or reduce the severity of common coding mistakes, is yet another layer that can be deployed in this ongoing battle, and given the ease and low cost of this defense, it is one worth deploying in your applications.
BiographyNick Wienholt is an independent Windows and .NET consultant based in Sydney, Australia. He is the author of Maximizing .NET Performance from Apress, and specialises in system-level software architecture and development with a particular focus on performance, security, interoperability, and debugging. Nick can be reached at NickW@dotnetperformance.com.
Page 2 of 2