The Buffer Overflows Research Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Abstract- this paper will try and explain the concept behind buffer overflows. It will give a back ground into what buffer overflows are, their vulnerabilities, how they can be exploited and the methods used [1]. Considering that buffer overflows are still a significant problem in the current computing world, a fundamental guideline for the necessary steps in buffer overload attacks prevention will be discussed. Also, the paper will discuss how the computer industry have adapted to the dilemma of buffer overflow.


A buffer is an area of memory that can be used to store user input. Buffers are created to contain a finite amount of data.

Fig 1.1: Graphical image of a buffer

A buffer overflow occurs when a program or process tries to store more data in a buffer that it was intended to hold. Using the analogy of pouring 10 litters of water into an 8 litter glass, the extra information, two litres of water in this case, has to be placed in some location[3]. This extra information may overflow into adjacent buffers, corrupting or overwriting the valid data held in them[9]. This may result in erratic program behaviour, including memory errors, incorrect results, a crash (server maybe) or a breach of system security.


The first recorded buffer overflow that caused damage was released in 1988 by Robert Morris. He is a graduate student from Cornell and is the son of a NSA chief scientist.

His overflow was a worm based program and was intended to propagate slowly and harmlessly measure the size of the internet. But due to a code error, it created several copies as fast as it possibly could and overloaded infected machines. This worm infected around 6000 machine. Not a significant number, but in 1988, it was approximately 10% of the internet and cost amounted to between $10-100 million damages. The outcome of this buffer overload from Morris resulted in a conviction under the Computer Fraud and Abuse Act, and he was consequentially sentenced to 3 years of probation with 400 hours of community service.

Morris was the first of many attacks, below is a list of the most infamous buffer overflow attacks.

Morris (1988) - overflow in fingerd.

CodeRed (2001) - overflow in MS-IIS server resulting in 300,000 machines infected in 14 hours.

SQL Slammer (2003) - overflow in MS-SQL server resulting in 75,000 machines infected in 10 minutes.

Sasser (2004) - overflow in Windows Local Security Authority Subsystem Service (LSASS) operating systems. This is responsible for enforcing the security policy on the system. It verifies user logging onto a Windows computer or server handles password change and creates access tokens. Resulting in around 500,000 infected.

Conficker (2008-09) - overflow in Windows server resulting in around 10 million machines infected (estimates vary)

Programming languages such as C and C++ suffer mostly from buffer overflow as they are older generation languages. For newer languages, the overflow of a buffer is normally detected and prevented automatically. C and C++ will simply let the additional data be added all over the rest of the memory resulting in serious exploitation. These methods of exploiting buffer overflows will be examined below but first we must look at the memory structure and see where these overflows happen within the buffer.


In order to understand buffer overflows, we must consider the memory structure itself and how it operates.

The memory structure can be broken down into two segments:

Text Area

Data Area

Data then may be broken down further into three logical parts:

Static data

Stack data

Heap Data

The difference between these parts is how the memory is allocated, stored or located. It is within these sections that overflows can over.

Fig 1.2: Graphical image of a memory structure

Text Area

The text area is used to store program instructions and can only be read. It cannot the altered or written too.

Static Data Area

Static data is pre-known information whose storage space is compiled into the program.

Stack Data Area

Stack data area contains return address, local variables and function arguments.

Heap Data

Heap data is memory that is dynamically allocated by the

application at run-time with the use of malloc and calloc.


Now that the memory structure is explained, a simple program written in C language below will demonstrate a buffer overflow.

Void get_input () {

char buf [1024];

get (buf);


Void main(int argc, char * argv[]) {



This program specifies 1024 characters it can store. Using the get_input function, the user input is read. If the user inputs over 1024, the buffer will overflow and become vulnerable.

Buffer overflows are thus the basis of many software vulnerabilities and can be maliciously exploited. There are a other means to exploit buffers with overflows. The paper will focus on the two main types of attacks using buffer overflows, of which are the stack overflow attack and the heap overflow attack. Utilising these attacks, the perpetrator may gain access to a host computer and its required data, and further, may simply inject a virus.


It is firstly necessary to question what is a stack?

Fig 1.3: Graphical image of a simple stack

A stack can be defined a data structure that stores information about the active subroutine of a computer program[12].

The purpose of a stack is for:

storing the return address of a subroutine

local data storage

pointer to current instance

enclosing subroutine context

parameter passing

Stack operates on the first-in-last-out structure (FILO); last object placed on the stack will be the first object removed using the PUSH and POP method. PUSH adds elements at the top of the stack. POP removes the last element at the top of the stack, thus reducing the stack size by one[8].

When using the stack, it can be manipulated for attacks, this is where stack buffer overflow attacks occurs. This method of attack can enable a host computer to be hacked, therefore breaching security. There are a small amount of methods involved with this type of attack. These methods are:

Altering the programs behaviour by overwriting a local variable that is near the buffer in memory on the stack or simple injecting code[6].

Overwriting the return address in a stack frame. Once the function returns, execution will resume as specified by the attacker.

Figure 1.4: ReturnAddress Attack [11]

Overwriting a function pointer, or exception handler, that is subsequently executed.

Fig 1.5:Pointer Attack[11]

Altering frame pointer.

Figure 1.6:Frame Pointer attack[11]

Taking advantage of these methods will allow an attacker to use buffer overflows to attack a host computer. The Stack buffer overflow and is still regarded a considerably large scale attack.


Fig 1.7:Heap Overflow

Heap overflow happen in a different section of the memeory stucture to that of a stack buffer overflow. The occurance causes the memory to dynamically allocate data by an application at run time and that typically contains program data. The attacks is carried out by overflowing buffers on the heap and changing pointers that point to important data. The heap overflow method techniques overwrite these pointers in the dynamic memory allocation linkage and uses the resulting pointer exchange to overwrite a program function pointer. This attack is not as simple as the stack buffer overflow attack but have the same consequences.

These attacks may be minimised by deploying methods that make it difficult for the hacker/attack, whereby preventing the buffer overflows that inflict damage. These methods involve testing for buffer overflow vulnerabilities, establish prevention methods, and follow phases and to ensure there are no vulnerabilities.


Buffer Overflow cannot be prevented completely but a few methods have being developed in software and hardware to help aid in the porcess of portecting against buffer overflow vulnerabilities.

There are 4 basic techniques.[13]

Static analysis

Complier modification

Operating System modifiaction

Hardware modification

Static Analysis

This refers to the discovery of a problem and the solution problem before an attack can take place. This is achieved by proforming some analysis on either the source code or complied binaries. The code may contain a predefined signature for example. Tools have being developed to aid in this type of prevention. FlawFinder, RATS & OpenBSD projects just to name a few.

Compiler Modification

There are a number of tools developed to modify compliers to help catch attacks and prevent them. The most successful of these tool would be StackGaurd, StackShield and Return Address Defender(RAD).

StackGuard was developed to aid the C-language complier[3]. It inserts a marker, known as a canary, between the frame pointer and the return address on the stack. If a atttack took place, the canary would be overwritten and altered resulting in the dection of an attack.

StackShield is a security add on developed by Linux. It operates with GNU Complier Collection. StackShiled adds instructions during compilation that causes a program to maintain a seperate stack of return address in a differ data segment. StachShield can also implement a boundary check on function calls and function return address. If a process is not within the boundary range, StackShield assumes an attack has taken place and stops the process.

Return Address Defrnder -RAD operates by recording a second copy of the return address. If the address is change and does not match the copy, RAD assumes a attack has taken place and takes appropriate action.

Operating System modifaction

The operating system may be modified to help prevent buffer overflows. These modifications consist of making the stack segment to be non-executable. Another modification could be the modification of the programme library called Libsafe. This interacts all calls to functions know to be vulnerable and ececues a safe version of those calls. There are a nuber of operating system modifications and memtioned above are just a few options.

Hardware modification

The development of SmashGaurd is a popular hardware-based solution to buffer overflows. SmashGuard is a hardware stack thats checks on each call function[14]. The function call address is push onto the hardware stack and is compared to the return address. If different, an exception is raised to signal a mismatch.

Another address protection using hardware would be SplitStack and SRAS(Secure Return Address Stack) but these hardware prevention techniques are not as efficient as SmashGaurd.

These prevention techniques mentioned above all are well and good but have a few draw backs. First off all the prevention of buffer overflow is not 100% guaranteed and for the software modifactions, a drawback is that it will add overheads to the process resulting in a delayed and slower processing time.

Hardware solutions have being proven to provide greater protection than existing software preventions and hardware modifications are more difficult to attck.


When a programmer or test engineer is developing a new application or program, they should follow the given phases below to prevent the effects of buffer overflow.

For a programmer:[5]

Is there bounds checking on arrays?

Is there bound checking on pointer arithmetic?

Is there any provision for checking before copy to, format, or send input to a buffer, for making sure that it is big enough to hold whatever might be thrown at it?

Is there any provision of checking the input because input itself might cause a buffer overflow and on the size of the input?

Is there a correct use of unsafe library functions?

Is there any provision for checking of f-by-one errors?

Is this clear that an array declared in C as int A[100] can only be accessed with indices A[0] through A[99]

Is there any provision for checking old code?

Are all the assumptions taken with attackers/hackers point of view?

Is it considered that all buffer overflows are a security risk

For a test engineer:[5]

Is there a checking of all string and buffer inputs by entering a very long string or too much data?

Is there any checking for one number in the partition?

Is there any check for each partition of value or size on any input?

Is there any provision for testing of old code when programmers are using it for new things, even if it's tested before?

Is the code tested on all platforms it was supposed to run on?

Are all the assumptions taken with the attacker's/hacker's point of view?

Is it considerer that all the buffer overflows are a security risk?

From utilising these checklists, it was proven that the risk of attack through buffer overflow was reduced significantly by up to 80%.


Buffer overflows are still a major sector in computing. The ability to manipulate them and use their vulnerabilities for attack/hack purposes is still a major issue, and plans to be so for the forseeable future. This issue cannot be elimated completly, but preventions are ongoing to eleminate some aspects of the buffer overflow situation.

Over 50% of CERT (Computer Emergency Response Term) vulnerability announcements were due to buffer overflows[2], and the most recent attack happened within recent years. This proves that the efforts to secure buffer overflow will still continue for the forseeable future.