How 'buffer overflow' attacks work
By Peter Coffee, eWEEK Technology Editor
July 20, 2000 10:42 AM ET


A "buffer overflow" attack deliberately enters more data than a program was written to handle. The extra data, "overflowing" the region of memory set aside to accept it, overwrites another region of memory that was meant to hold some of the program's instructions. The values thus introduced become new instructions that give the attacker control of the target computer. 

The form of the attack 

A running computer program is a lot like a printed form. There are spaces for data to be entered, and there are instructions for what to do with that data. But forms are printed in ink on paper, making them difficult to alter except by filling the spaces deliberately provided; most computer programs, by contrast, run in forms of computer memory that are designed to be easy to change, with data and instructions each using different portions of a single "address space" of memory locations. 

If you could enter more data than a space on a paper form could hold, and if the excess data replaced nearby instructions with whatever you chose to insert, then printed forms would be subject to the "buffer overflow" attack. Where your income tax return provides a nine-digit space for your social security number, for example, you could enter instead an enormous string of numbers and letters: You could begin with the social security number, copy and rewrite the rest of the forms and instructions, but alter the tax rate tables to lower your personal tax liability. 

Altering your own copy of the tax tables won't help you get past an audit, but what if your attack could alter the master copy of the tables at the headquarters of the Internal Revenue Service? A buffer overflow attack against a server can have that kind of effect. 

An attack against client computers, like the Outlook date field vulnerability that came to light this week, can force any number of systems to follow revised instructions that enter through covert channels -- including, for example, instructions that have the effect of disclosing confidential information or damaging users?files. 

Prevention has a price 

Buffer overflow attacks are not new. The infamous Morris worm that afflicted the Internet in 1988 used a buffer overflow; the issue of buffer overflow risks to computer systems has been recognized since the 1960s. 

Buffer overflows can be prevented by writing programs that validate the size and, ideally, the type of the data that they accept. Validation can be part of any process in which data is exchanged between a user and a system, or between different parts of a system. 

But data validation takes time, and on networks it may occupy scarce bandwidth as system elements exchange validation rules. 

Some Internet-related technologies, such as the Java language and its underlying platform, incorporate notions of data size and type in a rigorous manner. It requires deliberate, sophisticated techniques to evade Java's overflow protections. 

Other widely used Internet technologies, such as the C and C++ programming languages, have no explicit notion of data element size for collections such as arrays. Their balance between convenience and protection is at the opposite extreme from Java's, with C or C++ developers being forced to write their own explicit logic to check for every possible overflow attack. 

Writing "guard logic" is not technically difficult, but it is time-consuming and likely to be neglected. A 1990 study of utility software on Unix systems, for example, found that roughly a third of the examined programs could be crashed by various forms of random input, including over-long input strings. 

As Internet service providers and users become more aware of obvious attacks, such as e-mails with active attachments, the energy of Internet attackers will shift toward overflow attacks. These require more detailed knowledge of system internals, unlike Melissa-style attacks that merely use published system features in malicious ways. The bad news is that overflow attacks pose far greater challenges to our systems' protective tools, and that only disciplined attention from application developers can effectively block this threat.