Buffer overruns and the C run-time library

For years, buffer overrun exploits were some of the most common ways that attackers breached the security of computer systems, applications and Web sites. About four years ago, Microsoft decided to do something about its part of the problem, and added “secure” string handling functions to the C runtime library.

Those enhancements shipped with Visual Studio 2005. I vaguely remember reading about them, especially in an article by Michael Howard entitled Saying Goodbye to an Old Friend, which unfortunately seems to have disappeared. At the time I was writing more C# and Python than C++, so I didn’t pay much attention.

Early this year, I moved an old C++ code base (an ActiveX control) from Visual Studio .NET 2003 to Visual Studio 2008, jumping right over Visual Studio 2005. In addition to facing a bunch of incompatibilities that needed to be fixed before the code would even compile successfully, I was confronted by a slew of warnings about deprecated functions. When I had time to address them, I did, mostly by converting old-style function calls to their new “secure” form.

For example, I converted calls from strncpy to strncpy_s, and from strncat to strncat_s. These invariably involved adding a parameter specifying the maximum number of characters to be copied. I did that, figuring out the best value in each case, and also used the opportunity to reexamine the buffer sizes.

One common case was a buffer for a file path. These typically were specified like this:

    char fullname[MAX_PATH], szPath[MAX_PATH];

You’d think that MAX_PATH (defined as 260) would be big enough for any file path, by definition, but it turns out that in the days of Unicode and enhanced file systems that isn’t really the case. It’s very difficult to create a path longer than 260 characters, but it can be done. It can also be loaded into the registry.

It took 4 or 5 months before I saw the error, but what the strncpy_s did in the case of a string longer than the destination buffer was not what I expected or wanted: it threw a C run-time error and aborted the process. Harsh.

It turns out there was a magic word I had missed. No, it wasn’t XYZZY or PLUGH: it was _TRUNCATE. Deep in the bowels of the cave, scratched on a wall, was the advice to use this magic word to cause the string functions to truncate the copied string safely, adding a null in the last remaining space, which was of course exactly what I wanted all along:

   strncpy_s(szPath, sizeof(szPath), p, _TRUNCATE);

Now you know.