A stack is a place that an application uses to store local data, function arguments, return addresses, and registers. The stack can be arranged in several different ways depending on how the compiler converts higher-level languages to assembly code, and even on how a compiler’s options are set. For now, let’s stick to how a simple C program works.

For historical reasons, the stack grows down; it starts at a fixed value (say, address 0x0012FF00) and then allocates local variables and pushes parameters into lower addresses. Obviously, this can lead to the problem of running out of stack space, causing the program to abort. You won’t normally run out of stack space unless the programmer has allocated a lot of data on the stack or there are a lot of function calls. One way to run out of stack space is by using recursion without limits. Recursion occurs when a function calls itself internally. A bigger problem is that if someone can overwrite a buffer, he can then overwrite important information. Let’s say I have a function named foo that that takes two parameters and then allocates a buffer on the stack. Figure 17-1 shows what the stack looks like inside the foo function.

Figure 17-1. A typical stack for a function taking two arguments.

A stack can be more complicated than the stack shown in Figure 17-1. Under some circumstances, the value in the EBP register can be stored on the stack between the buffer and the return address. How EBP is stored will turn out to be important later. If a compiler is used that supports return address checking, a value known as a canary is inserted between the local variables and the return address. If you’re looking at the stack in a debug build, things will look a little different because the compiler adds checks to try to find problems for you. Figure 17-2 shows what happens when the local buffer is overrun.

Figure 17-2. The stack after the local buffer is overrun.

If the buffer is overwritten with user-supplied data, the attacker now controls a number of interesting parameters. Your first problem is that the attacker controls the return address, or he controls the address of the next instruction the application will try to execute once it is done with the current function. A common approach is to cause the application to jump into instructions contained in the data that you supplied.

A slightly more sophisticated attack would involve a jump into another user-supplied buffer. There is a minimum practical size for exploit code, often known as an "egg" or shell code, because the most common attack is to get the victim application to give the attacker a command shell. If an overrun occurs in a small number of bytes, it might not look practical to write an exploit, but one way around the problem is to place the shell in a larger buffer that you don’t overrun, and then trigger a jump into the larger buffer. Just because the buffer is small doesn’t mean you’re safe. Even when the local buffer is small, if the overrun is unbounded, the attacker can write the shell code nearly as far as she wants into the stack, and then jump into the overwritten area.

Your second problem is that the attacker now controls the arguments passed into the function. If the arguments are pointers, or the addresses of other parameters or buffers further up the stack, and the function writes to those addresses after the buffer is overrun, even more mischief can occur.

A variant on a stack overrun doesn’t involve overwriting the return address. Depending on compiler options and how the function looks to the compiler, a CPU register value might get placed on the stack between the buffer and the return address. Forgetting that the storage needed for a string is one more than the number of characters in the string is a fairly common programming problem. For example, "Hello World" is 11 characters long, but with the terminating null (0) character, the string needs 12 bytes-worth of storage. So now you can have a buffer that’s overwritten by exactly 1 byte.

A 1-byte overflow doesn’t seem exploitable, but it is. And the exploit seems like it would be difficult, but it is actually fairly easy. The value stored in the register gets truncated by 1 byte. For example, 0x0012ffc0 becomes 0x0012ff00. This means that when the function that called this function returns, the flow of execution will be redirected to the address in the truncated value, not where it is supposed to. There are only two prerequisites for making an off-by-one overflow exploitable: the buffer size in bytes is divisible by four; and either the buffer is large enough to allow you to control the data in which the flow execution will land or there’s another buffer that you do control at that location. You can also overwrite other registers stored on the stack and turn that into an exploit.

What this boils down to is that if you can make an application blow up by giving it "malformed" input, a clever-enough person with exploit writing experience can frequently turn it into an exploit. One way to test for this is to feed a program a long string like "AAAAAAA" (but usually much longer). If the program says that it cannot execute the instruction at 0x41414141, you have a classically exploitable stack overrun. If the programmer tries to tell you that a buffer overrun isn’t exploitable, tell her that code that blows up isn’t acceptable and to go fix the bugs.

Some programmers think that when a buffer is allocated dynamically on the heap using a function call such as malloc, overrunning the buffer won’t be exploitable. They’re wrong about this.

The buffer overrun that led to the Blaster worm was a heap overflow. If you go to any vulnerability archive such as http://www.securityfocus.com, http://cve.mitre.org, or a vendor’s security site such as http://www.microsoft.com/technet/security, and search on heap buffer overflow, you end up with a number of hits. The people who write the exploits are doing more research to figure out ways to make heap overrun exploits more reliable, and the vendors are also trying to make memory managers more resistant to heap overruns. Both sides will probably make some progress. Exactly how to exploit a heap overrun is a fairly arcane topic, and the details vary depending on the operating system and version, and also sometimes on the application. Some applications implement their own memory management. The diagram in Figure 17-3 shows how many memory managers basically work.

Figure 17-3. A typical heap buffer.

From an attacker’s standpoint, there are a couple of ways to take advantage of the problem. The first and most obvious issue is that data in the adjoining buffer might be important. If the information in the next buffer includes the addresses of one or more functions, overwriting the buffer might be enough to cause the program to do what the attacker wants. The second way to create an attack is to get the heap manager to move the memory around for you. The metadata contains the size of this buffer, the size of the next buffer, and flags to let the memory manager know whether the buffer is in use, and other information of interest to the memory manager. When the buffer isn’t needed any longer, the application de-allocates, or frees, the buffer. During this process, the memory manager determines where the previous and next free buffers are located and writes the addresses into what was previously the beginning of the buffer. Figure 17-4 shows a diagram of a de-allocated heap buffer.

Figure 17-4. A de-allocated heap buffer.

If the attacker can overwrite the metadata for the next buffer, when the memory manager de-allocates the buffer, the memory manager can be tricked into writing 4 bytes of attacker-supplied data nearly anywhere in the application’s memory space. One of the most likely pieces of memory to attack would be a function’s return address, though there are many other portions of the application where 4 bytes could do as much damage.

A similar attack can be launched when a buffer is freed twice, and the attacker can either write directly into that buffer or the previous buffer between the first de-allocation and the second.

In programs written in C or C++, the printf family of functions is frequently used to write the output to the user. A common usage might be:

printf("Could not open file %s - error = %d
", filename, err);

In this example, the printf function takes the filename passed in and inserts it in place of the %s, and replaces the %d with the error number. The results might look like Could not open file c: empfoo.ini - error = 2, which tells us that C:TempFoo.ini was not found.

A number of format specifiers are available to the printf family of functions, and one of the most interesting is the %n specifier, which writes the number of bytes that should have been written to a certain point into the address provided to the function. How does an attacker give you format specifiers? Good question: this happens when you have a lazy programmer. Take a look at two ways to do the same thing:

printf("%s
", userinput); //this is the way it should be done

printf(userinput); //this will get your program compromised

The first example isn’t vulnerable. Here are the results from a sample application and an example of benign input:

E:	emp>format_string.exe "Hello World"
Hello World
Hello World

Now let’s see what happens if I start passing in some more interesting strings:

E:	emp>format_string.exe "%x%x%x"
%x%x%x
12ffc040110f2

You have some interesting differences in the output—%x returns numbers in hexadecimal (base 16) format. You are probably wondering just where the numbers came from. The printf function doesn’t know how many parameters were passed to it, and it operates on whatever data happened to be on the stack when it was called. If the number of format specifiers match the number of arguments, everything is fine. If there were no arguments and the attacker is supplying the data, the application will tell the attacker what’s on the stack. Nearly all the format specifiers just read data, but the %n specifier allows you to write data. If I invoke my sample application with:

E:	emp>format_string.exe "%x%x%n"

I get:

%x%x%n

Followed by the error message shown in Figure 17-5.

Figure 17-5. A Format_string.exe error message.

To test for format string problems, throw a few %x or %p specifiers into user input. If the specifiers are repeated back to you intact, you don’t have a problem. If you get back a bunch of numbers, you’ve found a problem.

The best countermeasure against buffer overruns is to be careful when writing a program that accepts user input, especially from the network.

Many operating systems and compilers also offer various levels of countermeasures against buffer overruns. All these countermeasures are capable of converting some exploitable conditions into denial of service attacks. No known buffer overrun countermeasure can completely save you once you allow an attacker to write into memory he shouldn’t have. Look at it this way: ABS brakes, seatbelts, and airbags can save your life if you happen to be involved in an accident, but you don’t see anyone who has all these countermeasures in place thinking it is OK to run around having accidents. It’s good to use all the available countermeasures, but doing so doesn’t mean that you can create sloppy code and maintain security.

Another countermeasure is to write applications in managed code. Managed code makes buffer overruns extremely difficult to encounter. Though theoretically impossible, managed code can call into unmanaged code, and overruns can occur inside the unmanaged code. Remember that managed code does not prevent you from making other types of security mistakes, and you might have performance reasons to write unmanaged code.

Like buffer overflows, integer overflows should be mitigated by writing solid code in the first place. If you’re writing managed code, the checked keyword can insert integer overflow checks, and the /checked+ compiler option can cause all code outside of a checked or unchecked block to check for integer overflows. If you’re writing C++, the SafeInt class can simplify the problem quite a bit.