Format Strings: Exploiting Memory Corruption Coding Vulnerabilities

To understand format string vulnerabilities, we must first look at how standard output functions work in the C programming language, specifically the printf family of functions (which includes printf, sprintf, fprintf, etc.).

The printf function is designed to take a "format string" as its first argument, followed by a variable number of additional arguments. The format string contains text to be printed, interspersed with format specifiers (like %d for integers, %s for strings, or %x for hexadecimal). When printf executes, it parses the format string. Every time it encounters a format specifier, it expects to find a corresponding argument passed to the function, which it reads from the stack and inserts into the output string.

The Vulnerability: Uncontrolled Format Strings

A format string vulnerability occurs when a developer allows user-controlled input to be passed directly as the format string argument to a printf function, rather than passing the user input as a separate argument.

Secure Code Example:

char userInput[100];
// ... user input is gathered ...
printf("%s", userInput); 

In this secure example, %s is the hardcoded format string. printf knows it should expect one argument (userInput), treat it as a string, and print it. If the user inputs %x%x%x, the program safely prints the literal text "%x%x%x".

Vulnerable Code Example:

char userInput[100];
// ... user input is gathered ...
printf(userInput); 

In this insecure example, the user's input is passed directly as the format string. This is the critical flaw. If the user inputs "Hello", the program prints "Hello". But what happens if the user inputs %x %x %x %x?

Because printf(userInput) is called, the printf function parses the input as a format string. It encounters the %x specifiers and assumes that the developer passed additional arguments to the function. However, the developer did not provide those arguments. Unfazed, the printf function simply reaches up into the memory stack and pops off the next available values, printing them out in hexadecimal format.

Weaponizing the Vulnerability

By controlling the format string, an attacker gains immense power over the application's memory space. This power manifests in two primary attack vectors: Information Disclosure (Reading Memory) and Arbitrary Memory Write (Writing Memory).

1. Information Disclosure (Reading Memory)

By injecting sequences of %x (hexadecimal) or %p (pointer address) into the input, an attacker forces the program to print out the contents of the stack. The stack contains highly sensitive data, including local variables, cryptographic keys, and, most importantly, memory pointers.

By analyzing the leaked stack data, an attacker can map out the application's memory layout. This is crucial for modern exploit development. Because modern operating systems utilize Address Space Layout Randomization (ASLR) to randomize memory locations and thwart exploits, a format string vulnerability provides the perfect mechanism to leak pointer addresses, defeat ASLR, and locate the necessary components to build a subsequent payload. Furthermore, by using the %s format specifier, an attacker can read the string data located at any specific memory address they provide, allowing them to dump the entire contents of the program's memory.

2. Arbitrary Memory Write (Writing Memory)

The most devastating aspect of a format string vulnerability stems from an obscure format specifier: %n.

Unlike all other format specifiers, which read data from the stack, the %n specifier writes data to the stack. Specifically, when printf encounters %n, it counts the total number of characters it has outputted so far, and it writes that integer value into the memory address pointed to by the next argument on the stack.

An attacker can weaponize this. By carefully padding their input string with dummy characters to manipulate the output character count, and by placing a specific memory address onto the stack, the attacker can use the %n specifier to write arbitrary values to arbitrary memory locations.

With the ability to write to arbitrary memory, the attacker can overwrite critical control structures, such as a function pointer in the Global Offset Table (GOT) or a saved Return Address on the stack. By overwriting a function pointer (e.g., changing the address of exit() to the address of the attacker's malicious shellcode), the attacker successfully hijacks the execution flow of the application. The next time the program attempts to call exit(), it executes the attacker's code instead, resulting in full system compromise.

While modern compilers have introduced warnings to help prevent format string vulnerabilities, they remain a significant threat, particularly in legacy codebases, embedded systems, and custom server applications.

A notable historical example involved a vulnerability in the Washington University FTP daemon (wu-ftpd), a widely used FTP server. The vulnerability existed in the SITE EXEC command handling. The server utilized a custom logging function that eventually passed user-supplied data—without proper sanitization or a hardcoded format string—directly to a syslog() call (which uses printf style formatting under the hood).

Attackers exploited this vulnerability by logging into the FTP server (often anonymously) and sending a SITE EXEC command packed with specially crafted format specifiers (%x and %n). By carefully manipulating the memory addresses and the character output count, attackers were able to overwrite function pointers within the FTP server's memory space. This allowed them to execute arbitrary shellcode with root privileges, leading to the widespread compromise of thousands of internet-facing servers. This incident highlighted how deeply embedded and dangerous a simple formatting error could be in a critical network service.

More recently, format string vulnerabilities continue to be discovered in IoT devices and router firmware. Many embedded devices rely on lightweight web servers and custom C binaries that were developed rapidly without rigorous security testing. When processing HTTP headers or URL parameters, these applications sometimes echo the input back to the user or write it to a log file using insecure sprintf or printf calls. Security researchers frequently leverage these flaws to bypass the device's web authentication, dump configuration memory to steal hardcoded credentials, and ultimately achieve remote code execution on the embedded device.

Eradicating format string vulnerabilities is entirely achievable through secure coding practices and leveraging modern compiler protections. Unlike complex logic flaws, format string bugs are specific, identifiable coding errors that can be prevented at the source.

1. Hardcode Format Strings

The absolute rule for preventing format string vulnerabilities is to never pass user-controlled input as the format string argument. The format string must always be hardcoded by the developer.

If a program needs to print user input, it must use a format specifier and pass the input as a subsequent argument.

• Vulnerable: printf(userInput);
• Secure: printf("%s", userInput);

Similarly, when using functions like syslog(), developers must explicitly define the format string:

• Vulnerable: syslog(LOG_ERR, userInput);
• Secure: syslog(LOG_ERR, "%s", userInput);

By enforcing this simple rule, developers completely neutralize the vulnerability, as the printf function will treat any malicious specifiers within the user input as literal text, not as commands to manipulate the stack.

2. Enable Compiler Warnings and Protections

Modern C/C++ compilers (like GCC and Clang) are highly adept at identifying insecure format string usage. Developers must ensure that their build environments are configured to flag these errors.

• Enable -Wformat and -Wformat-security: When compiling code with GCC or Clang, enable these flags. The compiler will analyze printf family function calls. If it detects a non-literal format string or a format string that cannot be verified at compile time, it will throw a warning (or an error, if -Werror is enabled). Organizations should configure their CI/CD pipelines to fail the build if these warnings are triggered.

3. Utilize Static Application Security Testing (SAST)

Integrate Static Application Security Testing (SAST) tools into the Software Development Life Cycle (SDLC). SAST tools automatically scan source code for known vulnerability patterns. They are highly effective at identifying unmitigated format string vulnerabilities across large, complex codebases, catching errors that might be missed during manual code review.

4. Implement Operating System Mitigations

While secure coding is the primary defense, operating system-level mitigations provide a critical safety net (defense-in-depth).

• Address Space Layout Randomization (ASLR): While format strings can be used to bypass ASLR, enforcing ASLR makes exploitation significantly more difficult, requiring the attacker to chain an information leak with their arbitrary write.
• Position Independent Executables (PIE): Compiling binaries as PIE ensures that the entire memory space of the application, including the code and data sections, is randomized, further complicating exploitation.
• RELRO (Relocation Read-Only): Enabling Full RELRO during compilation makes the Global Offset Table (GOT) read-only after the program loads. This prevents attackers from using a format string vulnerability to overwrite function pointers in the GOT, shutting down a primary vector for hijacking execution flow.