Troubleshooting Format String Exploits: Where's My Output?

// User input is passed directly as the format string.
// The program will try to interpret any format specifiers like %x or %n in the input.
printf(user_input);

// User input is passed as an argument to a static format string.
// The program will simply print the user_input as a string, no interpretation.
printf("%s", user_input);

Here's a list of common culprits in C/C++:

• printf
• fprintf
• sprintf
• snprintf (can sometimes be exploited, though less common)
• vprintf, vfprintf, vsprintf, vsnprintf
• syslog, err, warn

You can start with a broad search command in the root of the source code directory:

grep -rE "(printf|fprintf|sprintf|syslog)\(" .

This will give you a lot of noise. Your job is to sift through the results and look for calls where the first parameter is a variable that could be influenced by user input, rather than a string literal like "Hello, %s". If you see printf(buffer) where buffer comes from read(), recv(), or argv, you've likely found a bug.

Automated Tools: Your Digital Bloodhound

Manually grepping through a massive codebase is tedious. This is where automated SAST tools shine. Tools like Semgrep, CodeQL, and SonarQube have pre-built rules to detect dangerous patterns, including format string bugs.

For example, a simple Semgrep rule might look for any printf call where the argument is not a string literal. These tools can scan an entire application in minutes and point you directly to the suspicious lines of code, saving you a tremendous amount of time.

The Dynamic Poke: Making the Program Talk

Dynamic analysis, or DAST, involves running the program and interacting with it to see how it behaves. This is where we stop reading the blueprints and start knocking on the walls. This approach is essential for black-box testing where you don't have the source code.

The Classic Input Test: `%p` is Your Friend

The easiest way to test for a format string bug is to feed it format specifiers and see what comes out. The %p and %x specifiers are perfect for this, as they print data from the stack in hexadecimal format.

Imagine a vulnerable program that takes input from the command line:

#include <stdio.h>

int main(int argc, char **argv) {
    if (argc > 1) {
        printf(argv[1]);
        printf("\n");
    }
    return 0;
}

Let's run it with some test inputs:

$ ./vuln "Hello World"
Hello World

$ ./vuln "%p %p %p %p"
0x7ffee1b2e8a8 0x20 0x7ffee1b2e980 0x100

Look at that! The second command didn't print "%p %p...", it printed memory addresses from the stack. This is a definitive sign of a format string vulnerability.

To make it even clearer, you can prepend a unique string. If you see your string's hex representation in the output, you've hit the jackpot.

$ ./vuln "AAAA.%p.%p.%p.%p.%p.%p"
AAAA.0x7ffee81848a8.0x252e70252e70252e.0x70252e70252e7025.0xe8184980.0x100.0x41414141

See that 0x41414141 at the end? That's the hexadecimal representation of "AAAA". This confirms that our input is on the stack and is being read by printf. We have now 100% confirmed the vulnerability and its location.

Peeking with a Debugger (GDB)

When you want to be absolutely sure, a debugger like GDB is your best tool. By observing the program's state right before the vulnerable function call, you can see exactly what's happening.

Here's a quick workflow:

1. Load the program in GDB: gdb ./vuln
2. Set a breakpoint: Find the address of the printf call and set a breakpoint there. b *0x12345678.
3. Run the program with your payload: run "AAAA %p %p"
4. Inspect the stack: When the breakpoint hits, use a command like x/20wx $esp (on 32-bit) or x/20gx $rsp (on 64-bit) to view the stack.

You should see your input string ("AAAA %p %p") sitting directly on the stack, right where printf is about to read its format string from. This is the ultimate confirmation.

Static vs. Dynamic: Choosing Your Weapon

Both methods have their place. The most effective approach is to use them together. Start with static analysis to find candidates, then use dynamic analysis to confirm them.

Method	Pros	Cons	Best For...
Static Analysis (SAST)	Provides 100% code coverage; finds bugs early in development; highly scalable.	Can have high false positive rates; doesn't understand runtime context or configuration.	Auditing a full codebase to find all potentially unsafe function calls.
Dynamic Analysis (DAST)	Confirms exploitability with near-zero false positives; finds runtime-specific issues.	Only covers code paths that are executed; requires a running application; can be slow.	Verifying a suspected vulnerability in a live or test environment (black-box or white-box).

Key Takeaways: Your Bug Hunting Checklist

Finding the "where" of a format string vulnerability is a process of elimination and confirmation. Here’s what to remember:

• Know The Pattern: You are looking for user-controlled data being passed as the first argument to functions like printf.
• Start Broad (Static): Use grep or SAST tools to scan the entire codebase for suspicious function calls like printf(buffer). This gives you a list of leads.
• Confirm with Purpose (Dynamic): Test your leads by providing input like %p or AAAA%p%p%p. If you see memory addresses or your own string's hex code in the output, you've found it.
• The Fix is Simple: Once found, the fix is almost always to change printf(variable) to printf("%s", variable). This ensures the user input is always treated as data, not a command.

Happy hunting!