Buffer overflow attack:A potential problem and its Implications


Have you ever thought of a buffer overflow attack ? It occurs through careless programming and due to patchy nature of the programs. Many C programs have buffer overflow vulnerabilities because the C language lacks array bounds checking, and the culture of C programmers encourages a performance-oriented style that avoids error checking where possible. Eg: gets and strcpy ( no bounds checking ). This paper presents a systematic solution to the persistent problem of buffer overflow attacks. Buffer overflow attack gained notoriety in 1988 as part of the Morris Worm
incident on the Internet. These problems are probably the result of careless programming, and could be corrected
by elementary testing or code reviews along the way.

THE ATTACK :- A (malicious) user finds the vulnerability in a highly privileged program and someone else implements a patch to that particular attack, on that privileged program. Fixes to buffer overflow attacks attempt to solve the problem at the source (the vulnerable program) instead of at the destination (the stack that is being overflowed).

StackGuard :- It is a simple compiler extension that limits the amount of damage that a buffer overflow attack can inflict on a program. The paper discusses the various intricacies to the problem and the implementation details of the Compiler extension 'Stack Guard '.

Stack Smashing Attack :- Buffer overflow attacks exploit a lack of bounds checking on the size of input being stored in a buffer array. The most common data structure to corrupt in this fashion is the stack, called a ``stack smashing attack'' .

StackGuard For Network Access :- The paper also discusses the impacts on network access to the 'Buffer Overflow Attack'.

StackGuard prevents changes to active return addresses by either :-
1. Detecting the change of the return address before the function returns, or
2. Completely preventing the write to the return address. MemGuard is a tool developed
to help debug optimistic specializations by locating code statements that change quasi-invariant

" Canary StackGuard Overhead
" MemGuard StackGuard Overhead
" StackGuard Macrobenchmarks

The paper presents the issues and their implications on the 'IT APPLICATIONS' and discusses the solutions through implementation details of 'Stack Guard'.


BY:-Bablu Joshi

Ankit Agarwal


An overview to Buffer
Buffer overflow
Buffer overflow Attack
Counter measures
Stack Guard
Address Space Layout Randomly
Buffer overflow attack in terms of C language
Stack Smashing
Heap Attack
Function Pointer Attack
Return-into-libC Attack
Attacking Behaviours
Sniffing Traffic
Distributed Denial Of Services(DDOS)

Overview to Buffer overflow

Buffer: memory used to store user input, has fixed maximum size.
Buffer overflow: when user input exceeds max buffer size.
Extra input goes into unexpected memory locations.

Buffer overflow Attack: Buffer overflow attacks, the attackers injects in a sequence into the victim application and transfers the control of application to injected code.

Counter Measures

1. Stack Guard
1.1 Protection against hijacking of control flow
1.2 Canary to identify the overflow

2. WExecute
2.1 Either to write to a memory page or to execute
2.2 We cannot do both

3. Address Space Randomization
3.1 Address layout of program is randomized
3.2 ASLR implemented in July 2001
3.3 Three area of randomized in ASLR
3.3.1 Executable
3.3.2 Mapped
3.3.3 Stack
Buffer overflow attacks in terms of C language

Stack smashing attacks
Function calls results in an activation frame
being pushed onto a memory area called the
System function takes an arbitrary command line as an argument, checking the argument validity, loads into the register R.
The attackers can arrange for R to an attacker supplied string and system will treat attacker supplied string as command line argument and execute it.

Heap Attack
HEAP is a region of Virtual memory used by application.

Heap allocation has a min
size of 8bytes and additional
overhead of 8bytes.
Heap overflow techniques
overwrites dynamic memory
allocation linkage

Function Pointer Attack
Buffer overflow vulnerability appers where an application need to read external information such as character string.
The receiving buffer is relatively small compared to size of input string.
its means attacker can change information as it wants by overwriting.

Series of machine
language cmds
as a string that
leads to the
execution of the at
code by changing
the return address
to the address to
the address of the
attack code

Return-into-libC Attack
The attacker does not inject code to stack any more but instead executes a functions of the libC.

Cyber criminals gets information from many methods to obtain information, one now from keyboard by we say keylogging or key stroke logging.

Sniffing Traffic
Means that attacker is able to view network traffic and will try to steal information data.
It can be done through physical access to the network.
If stolen data is encrypted the attackers use a cracker to decrypt the data.

Peer-to-peer network enable sharing the files amongst users in such a way that computing power and network brandwidth required to these files are shifted from relatively few servers to user which request them.

Types of spamming Attacks

Poisioning: Client can be provided a content which doesn’t match with description.
Defection: Which slow down the downloading ratio.
Virus: Sending tile with virus on online shopping.
Identify: Where client anonmity is not protected.

Distributed Denial Of Services(DDOS)
Distributed denial of services attacker takes control of one computer to attack large number of computers.
Modes of Attacks
1. Consumption of network resources.
2. Tampering of configration information.
3. Physical destruction or alteration of network components.

In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory. This may result in erratic program behavior, including memory access errors, incorrect results, a crash, or a breach of system security.
Buffer overflows can be triggered by inputs that are designed to execute code, or alter the way the program operates. They are thus the basis of many software vulnerabilities and can be maliciously exploited. Bounds checking can prevent buffer overflows.
Programming languages commonly associated with buffer overflows include C and C++, which provide no built-in protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an array (the built-in buffer type) is within the boundaries of that array.
Technical description
A buffer overflow occurs when data written to a buffer, due to insufficient bounds checking, corrupts data values in memory addresses adjacent to the allocated buffer. Most commonly this occurs when copying strings of characters from one buffer to another.
Basic example
In the following example, a program has defined two data items which are adjacent in memory: an 8-byte-long string buffer, A, and a two-byte integer, B. Initially, A contains nothing but zero bytes, and B contains the number 1979. Characters are one byte wide.
Now, the program attempts to store the null-terminated string "excessive" in the A buffer. By failing to check the length of the string, it overwrites the value of B:
Although the programmer did not intend to change B at all, B's value has now been replaced by a number formed from part of the character string. In this example, on a big-endian system that uses ASCII, "e" followed by a zero byte would become the number 25856. If B was the only other variable data item defined by the program, writing an even longer string that went past the end of B could cause an error such as a segmentation fault, terminating the process.
For more details on stack-based overflows, see Stack buffer overflow.
The techniques to exploit a buffer overflow vulnerability vary per architecture, operating system and memory region. For example, exploitation on the heap (used for dynamically allocated memory) is very different from on the call stack.
Exploiting stack buffer overflows
The canonical method for exploiting a stack based buffer overflow is to overwrite the function return address with a pointer to attacker-controlled data (usually on the stack itself). This is illustrated in the example below:
An example with strcpy
#include <string.h>

void foo (char *bar)
char c[12];

strcpy(c, bar); // no bounds checking...

int main (int argc, char **argv)
This code takes an argument from the command line and copies it to a local stack variable c. This works fine for command line arguments smaller than 12 characters (as you can see in figure B below). Any arguments larger than 11 characters long will result in corruption of the stack. (The maximum number of characters that is safe is one less than the size of the buffer here because in the C programming language strings are delimited by a zero byte character. A twelve-character input thus requires thirteen bytes to store, the input followed by the sentinel zero byte. The zero byte then ends up overwriting a memory location that's one byte beyond the end of the buffer.)
Notice in figure C above, when an argument larger than 11 bytes is supplied on the command line foo() overwrites local stack data, the saved frame pointer, and most importantly, the return address. When foo() returns it pops the return address off the stack and jumps to that address (i.e. starts executing instructions from that address). As you can see in figure C above, the attacker has overwritten the return address with a pointer to the stack buffer char c[12], which now contains attacker supplied data. In an actual stack buffer overflow exploit the string of "A"'s would be replaced with shellcode suitable to the platform and desired function. If this program had special privileges (e.g. the SUID bit set to run as the superuser), then the attacker could use this vulnerability to gain superuser privileges on the affected machine.
The attacker also can modify internal variables values to exploit some bugs. With same example :
#include <string.h>
#include <stdio.h>
void foo (char *bar)
float My_Float = 10.5; // Addr = 0x0023FF4C
char c[12]; // Addr = 0x0023FF30

// Will print 10.500000
printf("My Float value = %f\n", My_Float);

/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Memory map:
@ : c allocated memory
# : My_Float allocated memory
- : other memory

*c *My_Float
0x0023FF30 0x0023FF4C
| |
foo("my string is too long !!!!! XXXXX");

memcpy will put 0x1010C042 in My_Float value.

memcpy(c, bar, strlen(bar)); // no bounds checking...

// Will print 96.031372
printf("My Float value = %f\n", My_Float);

int main (int argc, char **argv)
foo("my string is too long !!!!! \x10\x10\xC0\x42");
return 0;
Heap-based exploitation
A buffer overflow occurring in the heap data area is referred to as a heap overflow and is exploitable in a different manner to that of stack-based overflows. Memory on the heap is dynamically allocated by the application at run-time and typically contains program data. Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers. The canonical heap overflow technique overwrites dynamic memory allocation linkage (such as malloc meta data) and uses the resulting pointer exchange to overwrite a program function pointer.Microsoft's GDI+ vulnerability in handling JPEGs is an example of the danger a heap overflow can present.
Barriers to exploitation
Manipulation of the buffer, which occurs before it is read or executed, may lead to the failure of an exploitation attempt. These manipulations can mitigate the threat of exploitation, but may not make it impossible. Manipulations could include conversion to upper or lower case, removal of metacharacters and filtering out of non-alphanumeric strings. However, techniques exist to bypass these filters and manipulations; alphanumeric code, polymorphic code, Self-modifying code and return to libc attacks. The same methods can be used to avoid detection by Intrusion detection systems. In some cases, including where code is converted into unicode, the threat of the vulnerability have been misrepresented by the disclosers as only Denial of Service when in fact the remote execution of arbitrary code is possible.
Practicalities of exploitation
In real-world exploits there are a variety of challenges which need to be overcome for exploits to operate reliably. These factors include null bytes in addresses, variability in the location of shellcode, differences between environments and various counter-measures in operation

Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Popular Searches: bayesian attack graphmnar, problem statment of libraries project, market potential project report questionnaire, remote frame buffer protocol seminar report, problem for envormental science in marathi, project euler problem 25, potential consultants bangalore,

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  BUFFER, DRIVER & SWITCHING MODULE computer girl 0 1,087 11-06-2012, 05:45 PM
Last Post: computer girl
  electronic nose and its applications seminars report electrical engineering 6 9,583 13-02-2012, 10:34 AM
Last Post: seminar paper
  Automatic switching ON and OFF of lights in warehouses using micro processors and sen seminar surveyer 0 1,759 22-12-2010, 11:34 AM
Last Post: seminar surveyer
Last Post: project report helper
  ZIGBEE and GSM-SMS Based Conductor Temperature and Sag Monitoring seminarsonly 1 3,178 25-10-2010, 06:06 PM
Last Post: Wifi
  Analysis on Modeling and Simulink of DC Motor and its Driving System Used for Wheeled seminar presentation 1 1,693 06-10-2010, 03:27 PM
Last Post: project report helper
  Investigation and Analysis of Inception Voltage and Field Distribution seminar presentation 0 564 18-05-2010, 10:06 PM
Last Post: seminar presentation

Forum Jump: