Can a Canary solve the buffer overflow problem?
Jim Reavis
Network World on Security, 08/30/99
In the past year that SecurityPortal.com has been posting "Top News," we have literally sent out hundreds of security alerts. Many of them have been related to security exploits caused by buffer overflow vulnerabilities. This is one of the biggest security problems on the Internet today. The worst-case scenario with buffer overflows is that you surrender root access to the attacker, who then does absolutely anything he wants with your system.
Buffer overflow problems tend to be discovered, exploited and patched on a case by case basis, leading one to reasonably assume that many more are hidden in our servers and that others are introduced daily in new software releases. Reasonable questions to ask are: What are they? Why are they fixed reactively? What can we do about them?
Advertisement: |
A buffer overflow attack occurs when a hacker floods an input buffer on the execution stack with more data than is expected by the program. The attack data usually consists of three elements:
1. Using arbitrary strings to achieve the overflow. By trial and error, the author of the buffer overflow attack determines the amount of data required to induce an overflow condition.
2. Exploiting code. This is the program the hacker wants to run, usually something like a shell, so he can in turn run any additional commands on the system.
3. A new return address. Instead of the return address going back to the original function, a new return address is written, pointing to the start of the Exploit code. When the function returns, the Exploit code is executed.
As an example, suppose you have a program that asks you to input your Social Security number. In the U.S. this is, of course, a nine-digit number. But if the programmer didn't perform error checking on the input string because he assumed that the user would know what to enter, a hacker could input thousands of bytes worth of data to achieve the overflow condition. If the program being attacked is running in privileged mode (as root in Unix or Administrator on Windows NT), the attack code inherits those privileges and has full rights to the system. The labor-intensive portion of this exercise is finding where programs are vulnerable and what data is needed to cause the overflow.
There are several factors that explain why buffer overflows are so common. A huge amount of the existing applications are written in the C language. It is a very powerful language that is full of pointers, but there is no inherent bounds-checking that forces a pointer to only refer to its original array space. The responsibility for writing some of the error handlers lies with the programmer, not with the compiler.
When I was taking programming classes in college, the competition was to write the fastest, most functional programs with the fewest lines of code. If you are hosting a busy electronic commerce site on the Internet, servicing customers quickly means getting the very best performance you can out of your software. For a programmer working long hours to deal with the demands for performance and project deadlines, adding error checking into code is something that might only get done on a case by case basis. Particularly when the chance for faulty data seems remote, a programmer may decide that certain functions may omit the needed error checking.
While programming errors can cause buffer overflow conditions, how software is installed may determine how serious the exploit is. Some legacy daemons require root or full supervisory privileges in order to run. In many other cases, software may be installed with root privileges, when the software itself only requires minimal privileges. In general, the exploit will inherit whatever privileges the attacked program had.
Why are buffer overflow attacks solved in a reactive manner by the security industry? It's in the code. It is almost like a miniature version of the Y2K problem, except instead of everything going off on January 1, 2000, each buffer overflow goes off when it is found and exploited. The effort needed to proactively find buffer overflow problems is enormous. There is no easy way to put protective functions between the processor and legacy code without making the program inoperable. Here are some ideas that may help:
Principal of least privileges. Applications should only be assigned the minimal privileges they need. Do not install applications with super-user rights unless absolutely necessary.
Separate the data from the public interface. A compromised Web server should not result in data being exposed. The database server should be separated from the Web server by a firewall and the database server should not trust the Web server implicitly.
Keep those patches coming. Although this is labor intensive, the stakes are too high to be slow in patching known buffer overflows with published exploits.
Evaluate niche solutions that protect against buffer overflows. Vendors are beginning to develop hardened operating systems that move away from the concept of a super-user and break this down into multiple discrete privileges. There are also solutions that protect specific daemons against buffer overflow attacks. The catch may be that these solutions move you into a platform that you are not comfortable with, or do not work with your specific application needs.
Now to the canary: StackGuard is a DARPA-funded project that seeks to solve the buffer overflow dilemma through a compiler extension. Applications compiled with StackGuard will terminate when a buffer overflow attack is attempted. This functionality is achieved by placing a word value called a Canary (as in "canary in a coalmine") on the stack next to the return address. The attacker needs to overwrite the return address in order to get his exploit code to work but by doing so he will also overwrite the Canary value. The system will not continue if the Canary has been killed, and the attacker cannot guess the Canary value because it is randomly generated every time. There are currently some implementations of StackGuard available at the StackGuard Web site. Hopefully this technology will be implemented into other mainstream commercial products soon and buffer overflows will be a thing of the past.
RELATED LINKS
Aleph One: Smashing the Stack for Fun and Profit
Vulnerability in Netscape Servers Revealed
Network World, 08/26/99
Security company confirms accusations of a bug in AOL messaging software
Network World, 08/20/99
Hacker arsenals feature new weapons
Network World, 03/22/99
Memco nips buffer overflow attacks
Network World, 01/25/99
Archive of Network World on Security newsletters
Network World Security Alert will keep you up to date on the latest security holes and patches, with daily updates from key vendors, security organizations and Network World reporters. See the latest dispatches from the security here.
