Security Development Lifecycle (SDL) Banned Function Calls

Michael Howard
Principal Cyber-Security Consultant
Microsoft Corporation

June 2011

**This paper is derived from the book The Security Development Lifecycle, by Michael Howard and Steve Lipner, Microsoft Press, 2006.

Prohibiting the use of banned functions is a good way to remove a significant number of potential code vulnerabilities from C and C++ code. This practice is reflected in chapter 11 of The Security Development Lifecycle book, as well as in the SDL Process Guidance and Simplified Implementation of the Microsoft SDL whitepaper within the SDL Implementation phase.

When the C runtime library (CRT) was first created over three decades ago, the threats to computers were different; computers were not as interconnected as they are today, and attacks were not as prevalent. With this in mind, a subset of the C runtime library must be deprecated for new code and, over time, removed from earlier code. It's just too easy to get code wrong that uses these outdated functions and these types of errors lead to vulnerabilities. Even some of the classic replacement functions are prone to error too.

This list is the compiled library of known bad functions that should be removed to reduce vulnerabilities as part of your SDL practices. It is derived from experience with real-world security bugs and focuses primarily on functions that can lead to buffer overruns (24 Deadly Sins of Software Development; Howard, LeBlanc, and Viega 2009). Existing code must either replace the banned function with a more secure version or be re-architected so that the banned function is not used. For the functions marked as “recommended”, please consider this a strong recommendation and evaluate the function against your own security requirements, elevating them to “required” as necessary. In any case, none of the listed banned functions should be used in new code.

Notes:

• The banned functions are either required or recommended based on:
  • The assessed risk of the function with consideration of the overall difficulty of calling the function in a correct and “safe” manner.
  • The availability of a safe replacement and the complexity of implementing a replacement.
• Some of the function names might be a little different, depending on whether the function takes ASCII, Unicode, _T (ASCII or Unicode), or multibyte chars. Some function names might include A or W at the end of the name. For example, the StrSafe StringCbCatEx function is also available as StringCbCatExW (Unicode) and StringCbCatExA (ASCII).
• Obviously, you cannot replace a banned function with another banned function. For example, replacing strcpy with strncpy is not valid because strncpy is banned, too.

Table 1. Banned string copy functions and replacements

1 For StrSafe, * should be replaced with Cch (character count) or Cb (byte count)

Table 2. Banned string concatenation functions and replacements

Table 3. Banned sprintf functions and replacements

Table 4. Banned "n" sprintf functions and replacements

Table 5. Banned variable argument sprintf functions and replacements

Table 6. Banned variable argument "n" sprintf functions and replacements

Table 7. Banned "n" string copy functions and replacements

Table 8. Banned "n" string concatenation functions and replacements

Developers frequently replace functions like strcpy with the counted "n" version, such as strncpy. This practice is not recommended. In our experience, the "n" functions are also hard to secure (Howard 2004), so we have banned their use in new code.

Table 9. Banned string tokenizing functions and replacements

Table 10. Banned Makepath functions and replacements

Table 11. Banned Splitpath functions and replacements

Table 12. Banned scanf functions and replacements

Table 13. Banned "n" scanf functions and replacements

Table 14. Banned numeric conversion functions and replacements

Table 15. Banned gets functions and replacements

Table 16. Banned IsBad* functions and replacements

Table 17. Banned OEM conversion functions and replacements

Table 18. Banned stack dynamic memory allocation functions and replacements

For critical applications, such as those accepting anonymous Internet connections, strlen must also be replaced:

Table 19. Banned string length functions and replacements

Table 20. Banned memory copy functions and replacements

Table 21. Banned window messaging functions and replacements

Why the "n" Functions Are Banned

The classic C runtime, "n" functions (such as strncpy and strncat) are banned because they are so hard to call correctly. The authors have seen numerous errors calling these functions in an attempt to make code more secure. Note that we're not saying the replacements are perfect, but issues with the current "n" functions include non-null termination of overflowed buffers and no error returns on overflow.

The newer StrSafe and Safe CRT functions are more consistent on failure.

Important Caveat

Simply replacing a banned function call with a better replacement does not guarantee that the code is secure. It's possible to misuse the replacement function, most commonly by getting the destination buffer size wrong.
One way to make sure the function call is safe is to double check that the numberOfElements argument in a Safe CRT function call (such as strcpy_s) or the cchDest argument in a StrSafe function (such as StringCchCopy) is no larger than the destination buffer size. A good way to do this is to use a _countof(buffer) call. Examples are shown later in this document.

Choosing StrSafe vs. Safe CRT

There is an overlap between these two sets of replacement C runtime functions. Which you choose depends on your specific situation; the following table should help you make the decision. In some cases, you might have little choice but to use one over the other; for example, if your code calls itoa, there is no replacement in StrSafe, but there is in Safe CRT. You would need to either code around the itoa call or use Safe CRT.

Table 22.

Using StrSafe

To use StrSafe in your C or C++ code, simply add the following header:

#include "strsafe.h"

This will make the functions inline. If you want to use the library version, Strsafe.lib, add the following to your code:

#define STRSAFE_LIB
#include "strsafe.h"

Note that all the StrSafe functions include Rtl versions for kernel use.

StrSafe Example

The following code

void Function(char *s1, char *s2) {
    char temp[32];
    strcpy(temp,s1);
    strcat(temp,s2);
}

when converted to StrSafe might look like this:

HRESULT Function(char *s1, char *s2) {
    char temp[32];
    HRESULT hr = StringCchCopy(temp,_countof(temp), s1);
    if (FAILED(hr)) return hr;
    return StringCchCat(temp,_countof(temp), s2);
}

Using Safe CRT

The Safe CRT is included starting with Visual Studio 2005. When you compile code using this compiler, it will automatically warn you of the deprecated functions in the code. Also, in some cases, the compiler will change some function calls to safe function calls if the destination buffer size is known at compile time and CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES is #defined in the code.

For example, the following code

int main(int argc, char* argv[]) {
    char t[10];
       ...
    if (2==argc) 
        strcpy(t,argv[1]);

       ...
    return 0;

}

is changed by the compiler to this:

int main(int argc, char* argv[]) {
    char t[10];
   ...
   if (2==argc) 
       strcpy_s(t,_countof(t),argv[1]);

   ...
   return 0;
}

Safe CRT Example

The following code

void Function(char *s1, char *s2) {
    char temp[32];
    strcpy(temp,s1);
    strcat(temp,s2);
}

when converted to the Safe CRT might look like this:

errno_t Function(char *s1, char *s2) {
    char temp[32];
    errno_t err = strcpy_s(temp,_countof(temp), s1);
    if (!err) return err;
    return strcat_s(temp,_countof(temp), s2);
}

Other Replacements

If you are using C++, you should seriously consider using the std::string template class rather than manipulating buffers directly.

Many *nix variants, including OpenBSD and some Linux operating systems, include support for string copy replacements strlcpy and strlcat (Miller and de Raadt 1999).

Tools Support

The Visual Studio 2005 (and later) compiler has built-in deprecations for these functions; all C4996 compiler warnings should be investigated to make sure that the function in question is not on the preceding banned list. Also, look out for code that disables this warning, such as #pragma warning(disable:4996).

ROI and Cost Impact

As stated earlier, removing banned functions is one way to reduce potential security bugs with very little engineering effort, as can be seen at the start of this document. Some Microsoft security bulletins would not have been necessary if banned functions had not been used, so the potential cost savings for an organization can be significant.

Metrics and Goals

The metric to track is the number of banned functions in former code and in new code. The quantity should be zero for new code and should follow a glide path down over time for former code.

References

(Howard, LeBlanc, and Viega 2009)

Howard, Michael, David LeBlanc, and John Viega. 24 Deadly Sins of Software Development. New York, NY: McGraw-Hill, 2009. Chapter 5, "Buffer Overruns."

(Howard 2004)

Howard, Michael. "Buffer Overflow in Apache 1.3.xx fixed on Bugtraq—the evils of strncpy and strncat," https://blogs.msdn.com/michael_howard/archive/2004/10/29/249713.aspx, October 2004.

(Miller and de Raadt 1999)

Miller, Todd C., and Theo de Raadt. USENIX Annual Technical Conference, "strlcpy and strlcat – Consistent, Safe String Copy and Concatenation," https://www.usenix.org/events/usenix99/full_papers/millert/millert_html/index.html, June 1999.