Major snares in C programming
A number of standard functions in the C language have great potential to get you in trouble. But not all of their uses are bad. Usually, exploiting one of these functions requires an arbitrary input to be passed to the function. This list includes:

• strcpy()
• strcat()
• sprintf()
• scanf()
• sscanf()
• fscanf()
• vfscanf()
• vsprintf
• vscanf()
• vsscanf()
• streadd()
• strecpy()
• strtrns()

The bad news is that we recommend you avoid these functions if at all possible. The good news is that in most cases there are reasonable alternatives. We'll go over each one of them, so you can see what constitutes their misuse, and how to avoid it.

The strcpy() function copies a source string into a buffer. No specific number of characters will be copied. The number of characters copied depends directly on how many characters are in the source string. If the source string happens to come from user input, and you don't explicitly restrict its size, you could potentially be in big trouble!

If you know the size of the destination buffer, you can add an explicit check:

if(strlen(src) >= dst_size) { 

  /* Do something appropriate, such as throw an error. */
  }
  else {
  strcpy(dst, src);

An easier way to accomplish the same goal is to use the strncpy() library routine:

strncpy(dst, src, dst_size-1);
  dst[dst_size-1] = '\0'; /* Always do this to be safe! */

This function doesn't throw an error if src is bigger than dst; it just stops copying characters when the maximum size has been reached. Note the -1 in the above call to strncpy(). That gives us room to put a null character in at the end if src is longer than dst.

Of course, it is possible to use strcpy() without any potential for security problems, as can be seen in the following example:

strcpy(buf, "Hello!");

Even if this operation does overflow buf, it will only do so by a few characters. Since we know statically what those characters are, and since they are quite obviously harmless, there's nothing to worry about here -- unless the static storage in which the string "Hello!" lives can be overwritten by some other means, of course.

Another way to be sure your strcpy() does not overflow is to allocate space when you need it, making sure to allocate enough space by calling strlen() on the source string. For example:

dst = (char *)malloc(strlen(src));
  strcpy(dst, src);

The strcat() function is very similar to strcpy(), except it concatenates one string onto the end of a buffer. It too has a similar, safer alternative, strncat(). Use strncat() instead of strcat(), if you can.

The functions sprintf() and vsprintf() are versatile functions for formatting text and storing it into a buffer. They can be used to mimic the behavior of strcpy() in a straightforward way. In other words, it is just as easy to add a buffer overflow to your program using sprintf() and vsprintf() as with strcpy(). For example, consider the following code:

void main(int argc, char **argv)
  {
  char usage[1024];
  sprintf(usage, "USAGE: %s -f flag [arg1]\n", argv[0]);
  }

We see code just like this pretty often. It looks harmless enough. It creates a string that knows how the program was invoked. That way, the name of the binary can change, and the program's output will automatically reflect the change. Nonetheless, something is seriously wrong with the code. File systems tend to restrict the name of any file to a certain number of characters. So you'd think that if your buffer is big enough to handle the longest name possible, your program would be safe, right? Just change 1024 to whatever number is right for our operating system and we're done? But no. We can easily subvert this restriction by writing our own little program to start the one above:

void main()
  {
  execl("/path/to/above/program", 
  <<insert really long string here>>, 
  NULL);
  }

The function execl() starts the program named in the first argument. The second argument gets passed as argv[0] to the called program. We can make that string as long as we want!

So how do we get around the problems with {v}sprintf()? Unfortunately, there is no completely portable way. Some architectures provide a snprintf() method, which allows the programmer to specify how many characters to copy into the buffer from each source. For example, if snprintf were available on our system, we could fix the previous example to read:

void main(int argc, char **argv)
  {
  char usage[1024];
  char format_string = "USAGE: %s -f flag [arg1]\n";
  snprintf(usage, format_string, argv[0], 
  1024-strlen(format_string) + 1); 
  }

Notice that up until the fourth argument, snprintf() is the same as sprintf(). The fourth argument specifies the maximum number of characters from the third argument that should be copied into the buffer usage. Note that 1024 is the wrong number! We must be sure that the total length of the string we copy into use does not exceed the size of the buffer. So we have to take into account a null character, plus all the characters in the format string, minus the formatting specifier %s. The number turns out to be 1000, but the code above is more maintainable, since it will not break if the format string happens to change.

Many (but not all) versions of {v}sprintf() come with a safer way to use the two functions. You can specify a precision for each argument in the format string itself. For example, another way to fix the broken sprintf() from above is:

void main(int argc, char **argv)
  {
  char usage[1024];
  sprintf(usage, "USAGE: %.1000s -f flag [arg1]\n", argv[0]); 
  }

Notice the .1000 after the percent, and before the s. The syntax indicates that no more than 1000 characters should be copied from the associated variable (in this case, argv[0]).

Avoiding internal buffer overflows
The realpath() function takes a string that can potentially contain relative paths, and converts it to a string that refers to the same file, but via an absolute path. While it's doing this, it expands all symbolic links.

This function takes two arguments, the first being the string to canonicalize, and the second being a buffer into which the result should be stored. Of course, you need to make sure that the results buffer is big enough to handle any size path. Allocating a buffer of MAXPATHLEN should be sufficient. However, there's another problem with realpath(). If you pass it a path to canonicalize that is larger than MAXPATHLEN, a static buffer inside the implementation of realpath() overflows! You don't actually have access to the buffer that is overflowing, but it hurts you anyway. As a result, you should definitely not use realpath(), unless you are sure to check that the length of the path you are trying to canonicalize is no longer than MAXPATHLEN.

Other widely available calls have similar problems. The very commonly used call syslog() had a similar problem until it was noticed and fixed not long ago. This problem has been corrected on most machines, but you should not rely on correct behavior. It is best always to assume your code is running in the most hostile environment possible, just in case someday it does. Various implementations of the getopt() family of calls, as well as the getpass() function, are susceptible to overflows of internal static buffers as well. If you have to use these functions, the best solution is always to threshold the length of the inputs you pass them.

It is pretty easy to simulate gets() on your own, security problem and all. Take, for example, the following code:

char buf[1024];
  int i = 0;
  char ch;
  while((ch = getchar()) != '\n')
  {
  if(ch == -1) break;
  buf[i++] = ch;
  }

Oops! Any function that you can use to read in a character can fall prey to this problem, including getchar(), fgetc(), getc(), and read().

The moral of the buffer overflow problem is: Always make sure to do bounds checking.

It's too bad that C and C++ don't do bounds checking automatically, but there is actually a good reason why they don't. The price of bounds checking is efficiency. In general, C favors efficiency in most tradeoffs. The price of this efficiency gain, however, is that C programmers have to be on their toes and extremely security conscious to keep their programs out of trouble, and even then, keeping code out of trouble isn't easy.

In this day and age, argument checking doesn't constitute a big drain on a program's efficiency. Most applications will never notice the difference. So always bounds check. Check the length of data before you copy it into your own buffers. Also, check to make sure you're not passing overly large data to another library, since you can't trust other people's code either! (Recall the internal buffer overflows we talked about earlier.)

What are the other risks?
Unfortunately, even the "safe" versions of system calls -- such as strncpy() as opposed to strcpy() -- aren't completely safe. There will still be a chance to mess things up. Even "safe" calls can sometimes leave strings unterminated, or encourage subtle off-by-one bugs. And, of course, if you happen to use a result buffer that is smaller than the source buffer, you might find yourself in a very difficult place.

These mistakes tend to be harder to make than everything else we've talked about so far, but you should still be aware of them. Think carefully when you use this type of call. Many functions will misbehave if you're not keeping careful track of buffer sizes, including bcopy(), fgets(), memcpy(), snprintf(), strccpy(), strcadd(), strncpy(), and vsnprintf().

Another system call to avoid is getenv(). The biggest problem with getenv() is that you should never assume that a particular environment variable is of any particular length. We'll discuss the myriad problems with environment variables in a subsequent column.

So far we've given you a big laundry list of common C functions that are susceptible to buffer overflow problems. There are certainly many more functions with the same problems. In particular, beware of third-party COTS software. Don't assume anything about the behavior of someone else's software. Also be aware that we haven't carefully scrutinized every common library on every platform (we wouldn't want that job), and other problematic calls probably exist.

Even if we examined every common library everywhere, you should be very, very skeptical if we tried to claim we've listed all the problems you'll ever run across. We just want to give you a running start. The rest is up to you.

Static and dynamic testing tools
We'll cover vulnerability detection tools in more detail in later columns, but it is worth mentioning now that two kinds of scanning tools have proven effective in helping to find and remove buffer overflow problems. The two major categories of analysis tools are static tools (in which the code is considered but never run) and dynamic tools (in which the code is executed to determine behavior).

A number of static tools can be used to look for potential buffer overflow problems. Too bad none of them are available to the general public! Many of the tools do little more than automate the grep commands you can run to find instances of each problematic function in source code. While better techniques exist, this is still a highly effective way to narrow a large program of tens or hundreds of thousands of lines into just a few hundred "potential problems." (In a later column, we'll show you a quick-and-dirty scanning tool based on this approach, and give you an idea of how it was built.)

Summary
In the past two installments of this column, we've introduced you to buffer overflows and given you guidance on how to write code to avoid these problems. We've also talked about a few tools that can help keep your programs safe from the dreaded buffer overflow. Table 1 summarizes the programming constructs we've suggested you use with caution or avoid altogether. If you have any other functions you think we should add to this list, please let us know, and we'll update the list.

In our haste to cover ground, we have left out, until now, some of the cool details behind buffer overflow. In our next couple of columns, we'll reach deep into the engine's workings and get greasy. We'll go into detail about how buffer overflows work, even showing you some exploit code.

Resources