Buffer Overflow refers to what happens when an area of a program’s code is overwritten with new code using the technique of inputting data longer than the length expected when the program asks for input. This creates an overflow in the program’s buffer system, and causes the program to react negatively − sometimes even resulting in system crashes. Hackers can cause buffer overflows intentionally to sabotage systems.

This overflow of data can be written to a critical program area, such as where execution code was placed. With carefully planned code overwritten in this area, a hacker can seize control of the program and, as a result, the system where the program resides.

The main reason a hacker can do this is due to negligence in the programmer’s coding. We call these types of problems “bugs” in the program. A common bug that leads to the possibility of a hacker causing a buffer overflow is when a coder neglects to include proper validation of data type and length for user input into the program.

Some common programming tools such as SQL commands allow a user to input carefully crafted responses to embed a request that triggers the program to execute a nested SQL command.

A good example of this is demonstrated in the following situation:

Consider a program that asks a user for input to find the name of a student by his or her surname. A proper input will trigger the program to successfully search the database for a match to the Surname inputted by the user, and return all records matching that surname. For example, suppose the input variable is named S_NAME. The input will execute the following SQL command:

Select * from Student_Table Where Student_Table.Name = S_NAME
This command instructs the program to locate all records with surname equal to S_NAME.

If a skilled user inputs something for S_NAME such as as “Select Surname from Student_Table”, then the program may execute the unexpected nested SQL command as:

Select * from Student_Table Where Student_Table.Name = Select Surname from Student_Table

This literally instructs the program to locate all records for all surnames in the Student_Table, and this is certainly not the original intention of the programmer who wrote the code. Depending on the subsequent codes of this program, this could possibly list all of the student names in a row − or simply crash the program, if it does not know how to handle the command.

The fact that a hacker can do this depends on three factors:

  • The hacker is an experienced SQL command writer
  • The hacker understands the underlying database structure of the program
  • The program does not exercise a careful input validation to verify the validity of the inputs

For the second factor, a hacker can come to understand the database structure in a lot of different ways. As we have noted in previous posts, most hackers are insiders of an organization. As such, they are able to gain access to related knowledge that aids in hacking. Another technique, Google hacking, is also an effective technique for hackers. (Click here to read our post on Google hacking.)

In the third factor, we’re talking about a bug in the program. If you have ever written computer programs, you probably understand that it is difficult − if not impossible − to write a bug-free program. Program input validation involves the consideration of so many exceptional input violation cases that a programmer cannot possibility foresee all of them. As long as even just one single case is missed (which usually is the case), the input process can be put into risk.

Throughout computing history, there are many examples of system exploitations by buffer overflow. Perhaps the most wide-spread example for Windows OS is one that happened in 2001, named “Code Red.”

If you are interested to know more about buffer overflow security incidents, refer to the information in Wikipedia:
http://en.wikipedia.org/wiki/Buffer_overflow