Testing for Format String Vulnerabilities

There are several different ways to test for format string vulnerabilities. Perhaps the most efficient way is through code review, but this strategy should be supplemented with additional black box cases, including manual security testing, fuzzing, and automation. In cases in which source code review gives limited coverage, additional binary profiling and analysis might be warranted depending on the circumstances. (Note that analysis is covered in Chapter 17, Observation and Reverse Engineering. ) The main focus should be on reviewing and testing places where untrustworthy data is processed by components written in C, C++, or related languages that might be vulnerable to similar attacks.

Note  

Although the examples in this chapter focus primarily on ANSI and numeric data, Unicode data is also typically vulnerable because attackers can specify input data that maps to Unicode (UCS-2) characters without null bytes. A number of clever ways have been formulated to create interesting payloads even if there are null bytes 0x00 forced into the data. Unlike the ANSI printf and related functions, programs that use Unicode use Unicode versions of these functions. The Unicode functions consider 0x0000 as a string terminator rather than just 0x00, so writing the actual exploit is sometimes easier because, unlike the ANSI equivalent, the Unicode payload can include single 0x00 bytes.

Reviewing Code

When you review code for format string vulnerabilities (unlike buffer overruns), it is typically more efficient for you to look for all of the places where format string specifiers are used than it is to try to divine or analyze where all untrustworthy input can seep in.

The code review process for format string issues is straightforward:

1. Obtain a list of functions that employ format strings to interpret the layout of the stack. See Table 9-1 to start.

2. Identify the format string parameter in each function. For many functions, it is the first parameter, but functions such as sprintf are the exception.

3. Use a favorite search utility (such as findstr or grep) and examine each usage for problems.

Taking the time to understand the tools and processes used to build the program being audited can pay off considerably. Consider compilers from Microsoft as an example. Microsoft Visual Studio 2005 includes a new version 8.0 runtime library that has a number of changes worth noting. One big change is that the %n format specifier is not supported by default, and it can be reenabled through the use of the _ set_printf_count_output function. (See http://msdn2.microsoft.com/en-us/library/ms175782(en-US,VS.80).aspx for details.) Note that even if the target program uses Microsoft Visual C++ 8.0 or later, it might still link to or use components compiled with a version of the runtime that supports the %n format string specifier. In addition, even with the %n specifier removed from the equation, an attacker can still do interesting things with %s and other format string specifiers, such as reading the data from any place in the program s memory. When reviewing code compiled with the Microsoft Visual C runtime version 8.0 or later, be aware that the code reviewer might need to look for a number of additional functions added to the runtime library. The functions in Table 9-1, for example, have at least three new variants per function. The printf function has similar printf_s , printf_l , printf_s_l , and printf_p functions defined. Using the secure version of the function such as printf_s is a good idea to help prevent buffer overruns, but these new functions are not especially designed to prevent format string attacks.

Black Box Testing

The general approach outlined here describes how to assess software manually for format string vulnerabilities.

1. Identify entry points.     Do not forget to include entry points in Java, the Microsoft .NET Framework, and other technologies if the data is processed by code written in C.

2. Craft interesting data.     In place of ordinary input, substitute %x , %d , and other format string specifiers. Often, one specifier will not cause an obvious problem, but long strings of % s%s%s%s and %n%n%n%n are needed to observe the problem in action.

   Important  

   Do not focus exclusively on places where data is formatted for display. Often, format strings are used to do other string operations such as data type conversion and string concatenation and insertion. Consider, for example, the format string vulnerability found in Weex, a noninteractive FTP client with a format string vulnerability in its caching code when connected to a malicious server. Read more about this vulnerability at http://www.securityfocus.com/archive/1/412808/30/0/threaded .

3. Get results.     Look for odd data and numbers to appear if the input data used specifiers (such as %x , %d , %s ) that read memory. The program might throw an exception if specifiers that reference other content (such as %s , %n ) are used.

   Tip  

   Why not make format strings a part of your ordinary test data formulation strategy? Instead of focusing exclusively on names like Chris Gallagher, why not make it a habit to try Chris %n%n%n%n%n%n%n%n%n%n%n%n%n too? Keep a text file of interesting characters and strings handy as you test, and add these to your manual and automated test cases.