Stopping Buffer Overruns

The buffer overrun is one of the most common security problems today. In fact, according to a CNET article (http://news.com.com/2100-1001-233483.html?legacy=cnet), it’s the most common security problem. You’ve probably read about buffer overruns in more than one place. A look through recent trade press magazines shows that a week doesn’t pass without news of yet another buffer overrun fix from one of the major vendors. It may seem as if buffer overruns are an unstoppable source of security problems for the developer, but they really aren’t. In fact, buffer overruns emphasize the need for various types of data checks, especially the length of the data.

The good news for .NET developers is that most causes of buffer overruns don’t affect you unless you regularly work with unmanaged code. CLR ensures that most causes of buffer overruns can’t occur by managing memory for you. However, any time you interact with any unmanaged code at all, your application is susceptible to this particular problem. Obviously, any problem that affects the .NET Framework due to problems in Microsoft’s coding practices will also affect you. Although you might be tempted to think of the .NET Framework as an entirely new world, you should realize that the Win32 Application Programming Interface (API) lurks underneath it all.

Understanding How Buffer Overruns Work

Buffer overruns rely on a somewhat strange idea. A cracker provides input to a program that exceeds the length of a buffer. The extra information ends up overwriting memory other than the memory controlled by the buffer. In some cases, the memory actually holds executable information. In other cases, the cracker overwrites the stack frame for the application and sends a return call to another location where the cracker’s code resides. The security community refers to these two types of attacks as:

• Stack buffer overflow

• Heap memory overrun

  Tip

  You can find an interesting Cyberguard paper on buffer overruns at http://www.utdallas.edu/~aph3x/docs/programming/security/overruns.pdf. The end of this document contains URLs that lead you to cracker code (with explanatory text) for buffer overruns.

A cracker doesn’t have to do something too weird to gain control of your machine. For example, the simple act of telling Windows to display a command prompt is enough to gain control of the system in some cases. If the system security is even a little lax, the cracker could gain control of the server. At the very least, a command prompt allows the cracker to probe the system looking for other ways to gain more access. Crackers don’t have to gain control of your system on the first try. A little gain here and a little gain there is all they need.

Keeping Exploits Controlled

The best way to control buffer overrun is to check every input your program receives, even from trusted sources. The problem of buffer overruns is so entrenched that you really can’t trust any source of information—not even your own code, because some operating system layer could contaminate the data. If you want to write truly secure code, then you need to make constant checks. See the “Checking the Data Length” section for an example of how to check data lengths in your code.

Tip

Microsoft provides a few recommended ways to control buffer overruns at http://msdn.microsoft.com/library/en-us/security/security/avoiding_buffer_overruns.asp . While this article isn’t very long, it is helpful. This article also lists a third form of buffer overrun called the array indexing error. However, none of the other security sources seems to recognize this exploit as a separate issue.

Developers complained about taking these additional measures in the past. For one thing, writing the addition code takes time. Unfortunately, code writing time is still an issue today, but one that you need to weigh against the cost of fixing problems later. It’s no longer convenient to put off writing the code you need today until tomorrow.

Another problem is that the error checking code affects performance. Machine resources were scarce in the past, so developers had a choice of writing fast code or safe code—the fast code usually won out. Today, machine resources are extremely cheap and plentiful. Even though the error checking code still affects performance, the performance hit is inconsequential in most cases. In sum, don’t accept the reasoning of the past as a way of avoiding extra coding time today.