Protect your code with Visual C + + defense features

Directory

Stack-based buffer overflow detection (/GS)

Security exception Handling (/SAFESEH)

DEP compatibility (/NXCOMPAT)

Image randomization (/dynamicbase)

More secure function calls

C + + Operator::new

What happens if it fails?

Many of the code is written in C and C + +, but unfortunately many of these types of code have security vulnerabilities that even developers do not know about. Programs written in any language have vulnerabilities that can cause their users to be attacked. But the C and C + + languages have a special place in the history of the Internet because many of their vulnerabilities stem from features that make them popular: Unlimited access to computer hardware and consequent performance benefits. When reading information about security and C or C + +, it is often easy to see terms like "buffering" and "overflow," since buffering is usually an example of direct access to memory. This type of direct access, while very powerful, is very, very dangerous.

Many of the buffer overflow problems that occur during the generation of C and C + + code can be caused by a variety of reasons. The first reason I have mentioned above is that the programming language provides direct access to vulnerable memory. The second reason is the developer error. A third reason is that the compiler does not usually provide defensive functionality. It is easy to provide a remedy for the first problem, but since C and C + + have been different languages.

Developer error issues can be partially addressed through training, but I haven't really seen the rise of educational institutions in this area. There are also some security training agencies in the industry, but we can only provide some solutions or part of the problem, and I would like to see more education about software security for students at universities. You might ask, "Why aren't educational institutions trying to train this very important topic?" To tell you the truth, I don't know why. But it's really frustrating.

Finally, even with top-notch training, some of the security issues are really complicated, and even well-educated engineers can't be completely solved. We humans are not perfect.

Building more defenses in the compiler is a problem that the Microsoft Visual C + + team has been trying to solve for years and is being improved with the help of our security team. This column outlines some of the buffer overflow defenses and other content available in Visual c++®2005. Note that some other compilers also provide defensive measures, but Visual C + + has two major advantages over compilers such as GCC. First, all of these defenses are integrated by default in the Toolset without downloading some bizarre add-ons. Second, these options are easy to use.

The defensive measures provided by the Visual C + + toolset include, in no order:

Stack-based buffer overflow detection (/GS)

Security exception Handling (/SAFESEH)

Data Execution Protection (DEP) compatibility (/NXCOMPAT)

Image randomization (/dynamicbase)

Automatic use of more secure function calls

C + + Operator::new

Before we discuss each item in detail, I would point out that these defenses do not compensate for unsafe code. You should always try your best to write the safest code, and if you don't know what to do, you can read some professional books on this topic first.

Typical Stack Compared to one Compiled with/gs

I would also like to point out that these are the requirements of Microsoft's Security Development Lifecycle (SDL), which means that you must use these options when writing C and C + + code, otherwise you cannot deliver. There are occasional exceptions, but very few, so do not discuss them in detail here.

The main point to keep in mind at the end of the

is that these well-designed defenses can also be bypassed, depending on the code. The more defenses the code uses, the harder it will be to solve it, but there is no defensive measure to be perfect. They are all meant to reduce the chance of being invaded. You must have learned something about it! The only solution is to use more secure function calls, which is a defensive measure that can really plug up vulnerabilities. Let's look at the various defensive measures in detail.