VC + + 2005 FAST Build Secure applications

First, Introduction

Microsoft's visual c++2005 release is the right choice for programming enthusiasts who are interested in writing safe and reliable applications easily and quickly. As you can hear, the new features of languages and libraries in Visual C + + make it easier to develop secure, reliable applications than ever before. It provides a powerful and flexible standard C + + and provides a suitable. NET Framework, the most powerful development language for programming.

In this article, I'll explore the new features of some languages and libraries in the visual c++2005 release, both for instructional projects and for large application engineering, which will help you improve your productivity when writing safe and reliable code.

Security features of the second and C Run-time libraries

If you are using Visual C + + to create an application that uses the C Run-time library, you will be relieved to learn that many of the library functions you rely on now have a more secure version. For functions that require one or more buffers as input, the length parameter has been added so that the function is convinced that it does not exceed the buffered bounds. More functions are now starting to check the arguments for legality, and the invalid parameter processor will be invoked if necessary. Let's take a look at some simple examples:

The most unreliable in the C Run-time library is the gets function, which reads one row from the standard input. Consider one of the following simple examples:

Char buffer[10] = {0};
Gets (buffer);

The first line of code declares a buffer variable and initializes the character in the buffer to 0. It is a good idea to initialize a variable to a well-known value in order to avoid unexpected occurrences. Then, the seemingly innocent gets function reads a line from the standard input stream and writes it to the buffer buffers. What's wrong with that? For a function, a C-type array cannot implement value passing, but instead passes a pointer to the first element of the array. So in a function, char[] is the equivalent of a char* pointer, and is a raw pointer that does not come with any extra information that determines the size of the buffer to which it points. So what does the gets function do? It assumes that the buffer is infinitely large (Uint_max has an exact size) and will continue to copy characters from the input stream into the buffer. Attackers can easily use this vulnerability, an obscure type error known as a buffer overflow.

Many of the original C Run-time library functions suffer from the same problem with parameter validation and are now being criticized. Keep in mind that performance is secondary to the application currently being written, and we are now living in a world of security first. Each critical function has been replaced by a function that provides the same function, but adds a security feature. Of course, depending on how much of the old library function you are using in the existing code, you may need to spend some time replacing the code with a newer, more secure version. These new functions have a _s suffix, for example, the gets function is replaced by the gets_s function, and the strcpy function that is attacked is replaced by the strcpy_s function. Here's an example:

Char buffer[10] = {0};
gets_s (buffer, sizeof (buffer)/sizeof (buffer[0));

The gets_s function has an extra parameter to display the maximum number of characters that can be written, including a null terminator. I used the sizeof operator, which determines the length of the array, because the compiler determines the result returned by the sizeof operator at compile time. Remember that the length of the sizeof return operand is in bytes, so dividing the array length by the length of the first element in the array returns the number of elements in the array. This simple method can be ported to the use of _getws_s under Unicode encoding, and this function also needs to know the length of the buffer in bytes.

As I mentioned, another common function strcpy function, like the gets function, has no way to guarantee a valid buffer size, so it can only assume that the buffer is large enough to hold the string to be copied. This will cause unpredictable behavior when the program is running, as I mentioned, and there is an example of using a secure strcpy_s function to avoid these unpredictable behaviors in order to be safe.

Char source[] = "Hello world!";
Char destination[20] = {0};
strcpy_s (destination, sizeof (destination)/sizeof (DESTINATION[0)), source);

There are a number of reasons to like this new strcpy_s function. The most obvious difference is the extra, byte-per-parameter, which is used to confirm the buffer size. This allows the strcpy_s function to perform run-time checks to determine that the written character does not exceed the bounds of the destination buffer. There are other methods of checking to determine the validity of the parameters. These instrumentation methods in the debug build, including the Assert assertions method that displays the debug report, display the debug report if their conditions are not met. Whether it is a debug or release version, if a particular condition is not met, an invalid parameter manager is invoked, and the default behavior is to throw an access violation to terminate the application. This is a great implementation to keep your application running without unexpected results. Of course, this can be avoided by ensuring that functions similar to strcpy_s do not invoke invalid arguments.

The previous example can be further simplified with the new _countof macro, which throws away the need for the sizeof operator with the wrong tendency. The _COUNTOF macro returns the number of elements in an array of type C. The macro itself corresponds to a template that, if passed a raw pointer, will not compile. Here's an example:

strcpy_s (destination, _countof (destination), source);