Skip to main content
Skip to main content
Microsoft Security

Compiler Security Enhancements in Visual Studio 11

  • Dave Ladd

In chatting with our colleagues in the MSEC Security Science Team, there were a number of interesting topics that weren’t covered in our previous Code Analysis blog post – information that would help contribute to the understanding of security features and functionality in Visual Studio 11.  So after some discussion, we have decided to release a series of posts covering this important work – everyone benefits from a better understanding of future technology offerings.

So with that, I again turn the blog over to Tim Burrell to elaborate!

_______________________________________

(Note – this blog post describes a feature in an unreleased product; this feature may be changed prior to final product release.)

Microsoft is actively developing Visual Studio 11 and continually looking for ways to improve security-related functionality. As part of this we are updating the /GS compiler switch, which is on-by-default and enables a basic level of code generation security features, with some enhancements beyond the now familiar cookie-based stack overflow protection. We’ll provide some more detail on these in a later post.

The Security Development Lifecycle (SDL) includes a number of recommendations beyond the scope of /GS where the compiler is able to assist secure software development. These range from specific code generation features such as using strict_gs_check to security-related compiler warnings and more general recommendations to initialize or sanitize pointers appropriately.

For the first time we intend to provide a central mechanism for enabling such additional security support via a new /sdl switch. The impact of /sdl is twofold:

          /sdl causes SDL mandatory compiler warnings to be treated as errors during compilation.

          /sdl enables additional code generation features such as increasing the scope of stack buffer overrun protection and initialization or sanitization of pointers in a limited set of well-defined scenarios.

This dual approach reflects our conviction that secure software is best achieved by the combination of detecting and fixing code bugs during the development process together with the deployment of security mitigations that will significantly increase the difficulty of exploiting any residual bugs.

The /sdl compiler switch is disabled by default, and can be enabled easily in the Visual Studio UI by opening the Property Pages for the current project, and accessing the Configuration Properties -> C/C++ -> General options.

So what does the /sdl switch do?

The features enabled by the /sdl switch are a superset of those enabled by /GS i.e. enabling /sdl enables everything included in /GS. We will be providing more background and in-depth details of the additional /GS and /sdl features in future posts. For now we note that they include:

The following SDL mandatory compiler warnings are enabled and treated as errors:

Warning Command line switch Description
C4146 /we4146 A unary minus operator was applied to an unsigned type, resulting in an unsigned result
C4308 /we4308 A negative integral constant converted to unsigned type, resulting in a possibly meaningless result
C4532 /we4532 Use of “continue”, “break” or “goto” keywords in a __finally/finally block has undefined behavior during abnormal termination
C4533 /we4533 Code initializing a variable will not be executed
C4700 /we4700 Use of an uninitialized local variable
C4789 /we4789 Buffer overrun when specific C run-time (CRT) functions are used
C4995 /we4995 Use of a function marked with pragma deprecated
C4996 /we4996 Use of a function marked as deprecated

 

If a developer wishes to opt in to most of the /sdl functionality but exclude a given warning ID (suppose C4146 for example) then this can be achieved by using the /wd switch to disable that specific warning under C/C++ -> Command Line -> Additional Options in the Visual Studio UI:

  • ·         The strict_gs_check pragma  is applied to all C/C++ code compiled with /sdl. This instructs the compiler to consider more functions as potential candidates for stack buffer overflow protection. The GS optimization introduced in Visual Studio 2010 has been improved to work better in conjunction with strict_gs_check, specifically enabling many of the extra security checks resulting from strict_gs_check to be proven unnecessary and removed.

Additional /sdl code generation features will be covered in more detail in later posts.

Microsoft strongly recommends using the /GS switch as in previous Visual Studio releases; the new /sdl switch in Visual Studio 11 presents an opportunity for greater security coverage both during and after development: stay tuned for more details on specific security benefits of using /GS and /sdl in Visual Studio 11.

Of course the Security Development Lifecycle (SDL) is an entire process and methodology for developing secure software and as such includes much more than just using specific compiler switches – read more and find additional resources related to SDL here.

Tim Burrell, MSEC security science.