Whidbey’s Secure CRT


One of the features that the Whidbey release of Visual C++ is going to bring is the new Secure CRT.  The C++ library team has put a lot of work into creating safe alternatives to the old C runtime library functions that seem to always be behind security exploits.  Michael Howard gave a quick introduction to this feature in his Code Secure column this month.


The new C functions are named similarly to the functions they’re intended to replace, but they have an _s suffix.  For instance, strcpy maps to strcpy_s.  Some functions that don’t need signature changes did not get renamed.  For instance calloc’s implementation has changed to check against integer overflow attacks, but since this does not affect the method’s signature or performance characteristics, it is still named calloc.  Although the changes to the CRT are not yet standardized, Microsoft has submitted them to ANSI, so hopefully in the future programs that take advantage of the new safer functions will be able to be ported to non-Microsoft compilers.  (The submission to the standardization committee can be found online at: http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n1031.pdf)


As an example of the mapping, strcpy went from being defined as:


char *strcpy(char *strDest, const char *strSrc); to


errcode strcpy_s(char *strDest, size_t sDest, const char *strSource);


The new functions do several things, including:



  • checking all input parameters

  • requiring buffer sizes

  • writing null terminators when writing string output

  • correctly ACL files

The way that invalid parameters are handled is especially interesting.  Instead of simply asserting, and quitting out, the CRT provides an opportunity for you to handle these problems through the _set_invalid_parameter_handler function.  You can do whatever you’d like in your invalid parameter handler, however as soon as it returns, the program will be exited.


On the C++ side of things, ATL and MFC have been updated to use the secure functions.  An addition being made to the STL is the concept of checked iterators.  These are iterators that won’t let you walk off the end of a STL structure.  In the event that an error is detected by the C++ library, there are two possible behaviors.  Setting _SECURE_SCL_THROWS to 0 (the default), the invalid parameter function will be called.  However, setting this macro to 1 will cause an exception to be thrown.


By default compiling a C/C++ program in Whidbey will result in warnings when functions need to be changed to their secure counterparts.  However, the enhancements made to the STL will not be available by default.  Instead, you must define the _SECURE_SCL macro to be equal to 1.


As we get closer to an official Whidbey release, the C++ team will be producing more documentation on these changes, and I’ll post links in this blog.

Comments (8)

  1. Jerry Pisk says:

    Does this mean that existing Microsoft’s CRT doesn’t check all input parameters? And the fix to that problem is not to fix the code but rather create new one? As for the rest – Microsoft already came up with StrSafe.h, does this mean that they will keep coming up and abandoning code every couple years or so? It’s probably that StrSafe.h was portable, so Microsoft felt like they need to come up with something that isn’t so they can yet again lock code onto their platforms.

  2. Shawn says:

    > Does this mean that existing Microsoft’s CRT doesn’t check all input parameters?

    That’s correct, but its not just Microsoft’s CRT. C libraries assume that all parameters passed into them are valid. If you use GCC and GLIBC, pass null into printf and see what happens, you’ll segfault. Even if they wanted to, due to function signatures it’d be impossible for CRT implementers to check all parameters. For instance, how can strcat check that the output buffer is big enough?

    > And the fix to that problem is not to fix the code but rather create new one?

    Again, fixing the code would break compatiblity with the C standard library. strcpy simply cannot check its output parameters.

    > Microsoft already came up with StrSafe.h, does this mean that they will keep coming up and abandoning code every couple years or so?

    StrSafe was developed during our security push in 2002. It’s still a valid and supported library, and will be shipped with Whibey as well. However StrSafe only fixed the C library string functions. The new Secure CRT improves many other C library functions (such as printf and calloc). It also improves the C++ library.

    > Microsoft felt like they need to come up with something that isn’t so they can yet again lock code onto their platforms.

    As I mention in my post, the secure CRT has been submitted for standardization. See http://std.dkuug.dk/jtc1/sc22/wg14/www/docs/n1031.pdf for details.

  3. Shawn says:

    John McCormick’s written a column on builder.com that points out these new features as well. You can find it here: http://builder.com.com/5100-6370-5185809.html

  4. A recent comment on the IE Blog made it pretty apparent that not everybody is aware…

  5. One of the cool new things we are doing in the security push is the conversion of all uses of potentially…