Using Safe String Functions

In 2002, Microsoft began an initiative to identify the common C and C++ functions that were prone to buffer overrun coding errors. These functions are not "bad" by themselves, but to be used securely they require extensive error checking on the part of the programmer. If that error checking is neglected (and it often is), the code will have a security vulnerability. Given the risk of this oversight, it was decided that it would be best to develop and promote a new set of functions to replace those prone to problems with a robust, thoroughly tested, and documented set of new ones.

These new functions, called Safe String Functions, are available from Microsoft for the Windows XP SP1 and later versions of the Windows DDK and Platform SDK. Many other commercial and freeware libraries that implement "safe strings" are available for common operating systems, processors, and compilers.

The following list (adapted from the article, "Using Safe String Functions," on msdn.microsoft.com/library) explains some of the benefits of using the new functions:

• Each function receives the size of the destination buffer as input. The function can thus ensure that it does not write past the end of the buffer.

• The functions null-terminate all output strings, even if the operation truncates the intended result. The code performing an operation on the returned string can safely assume that it will eventually encounter a nulldenoting the string's end. The data prior to the null will be valid and the string won't run on, indefinitely.

• All functions return an NTSTATUS value, with only one possible success code. The calling function can easily determine if the function succeeded in performing its operation.

• Each function is available in two versions. One supports single-byte ASCII characters and the other, double-byte Unicode characters. Remember from Chapter 10, "Foreign-Language Testing," that to support all the letters and symbols in multiple foreign languages, characters need to take up more than one byte of space.

Table 13.1 shows a list of the unsafe functions and the safe functions that replace them. When you and your team are performing code reviews or white-box testing, be on the lookout for the unsafe functions and how they are used. Obviously, your team's programmers should be using the safe versions, but, if not, your code reviews will need to be performed with much more rigor to ensure that any possible security vulnerabilities are addressed.

Table 13.1. The Old "Unsecure" C String Functions and Their New "Secure" Replacements

Old "Unsafe" Functions	New "Safe" Functions	Purpose
strcat wcscat	RtlStringCbCat RtlStringCbCatEx RtlStringCchCat RtlStringCchCatEx	Concatenate two strings.
strncat wcsncat	RtlStringCbCatN RtlStringCbCatNEx RtlStringCchCatN RtlStringCchCatNEx	Concatenate two byte-counted strings, while limiting the size of the appended string.
Strcpy wcscpy	RtlStringCbCopy RtlStringCbCopyEx RtlStringCchCopy RtlStringCchCopyEx	Copy a string into a buffer.
strncpy wcsncpy	RtlStringCbCopyN RtlStringCbCopyNEx RtlStringCchCopyN RtlStringCchCopyNEx	Copy a byte-counted string into a buffer, while limiting the size of the copied string.
strlen wcslen	RtlStringCbLength RtlStringCchLength	Determine the length of a supplied string.
sprintf swprintf _snprintf _snwprintf	RtlStringCbPrintf RtlStringCbPrintfEx RtlStringCchPrintf RtlStringCchPrintfEx	Create a formatted text string that is based on a format string and a set of additional function arguments.
vsprintf vswprintf _vsnprintf _vsnwprintf	RtlStringCbVPrintf RtlStringCbVPrintfEx RtlStringCchVPrintf RtlStringCchVPrintfEx	Create a formatted text string that is based on a format string and one additional function argument.

THE JPEG VIRUS

What could be more secure than a picture? After all, it's data, not executable code. That false assumption was broken in September of 2004 when a virus was discovered that was embedded in several pornographic JPEG images posted to an Internet newsgroup. When viewed, a virus was downloaded to the user's PC. No one thought it was possible, but it was. The problem lied in an exploitation of a buffer overflow.

The JPEG file format, besides storing the picture elements, also allows for the storing of embedded comments. Many software packages for editing and organizing pictures use this field for annotating the picture"Our family at the beach," "House for Sale," and so forth. This comment field starts with a hex value of 0xFFFE followed by a two-byte value. This value specifies the length of the comment, plus 2 bytes (for the field length). Using this encoding method, a comment of up to 65,533 bytes would be valid. If there is no comment, then the field is supposed to contain a value of 2. The problem is that if the value is an illegal entry of 0 or 1, a buffer overflow occurs.

It turns out that the code used to interpret the JPEG data and turn it into a viewable picture normalized the length by subtracting off the 2 bytes before it read out the actual comment. If the length byte was set to 0, subtracting off 2 yielded a length of -2. The code was written to handle positive integers and interpreted the negative 2 as a positive 4GB. The next 4GB of "comment" data was then loaded, improperly overwriting valid data and program. If that "comment" data was carefully crafted, hand coded, assembly, it could be used to gain access to the viewer's PC. Microsoft had to issue a critical update to all the components that loaded and viewed JPEG images.

Software vulnerabilities can occur where you never expect them. For this reason, it's imperative to consider software security in all aspects of a software product or system. From a user perspective, security is measure of quality. They may not ask for it, but they know they want it, and will consider lack of software security a bug (a huge one) if they don't have it. We'll close out this chapter with a brief visit to another aspect of computer security, one that's related to privacy, computer forensics.