Buffer Overflow Attack

Advertisement
 Download your Full Reports for Buffer Overflow Attack

What is buffer overflow?


A buffer overflow occurs when a program or process tries to store more data in a?buffer (temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information - which has to go somewhere - can overflow into adjacent buffers, corrupting or overwriting the valid data held in them. Although it may occur accidentally through programming error, buffer overflow is an increasingly common type of security attack on?data integrity. In buffer overflow attacks, the extra data may contain codes designed to trigger?specific actions, in effect sending new?instructions to the attacked computer that could, for example, damage the user's files, change data, or disclose confidential information. Buffer overflow attacks are said to have arisen because the?C programming language supplied the framework, and poor programming practices supplied the vulnerability.
In July 2000, a vulnerability to buffer overflow attack was discovered in Microsoft Outlook and Outlook Express. A programming flaw made it possible for an attacker to compromise the integrity of the target computer by simply it sending an e-mail message. Unlike the typical e-mail virus, users could not protect themselves by not opening attached files; in fact, the user did not even have to open the message to enable the attack. The programs' message header mechanisms had a defect that made it possible for senders to overflow the area with extraneous data, which allowed them to execute whatever type of code they desired on the recipient's computers. Because the process was activated as soon as the recipient downloaded the message from the server, this type of buffer overflow attack was very difficult to defend. Microsoft has since created a?patch?to eliminate the vulnerability.
Buffer overflows?are a favorite exploit for hackers. The vast majority of Microsoft's available patches fix unchecked buffer problems -- but what about applications developed in-house? They are just as susceptible as commercial applications to buffer overflow attack. It is therefore critical that you understand how they work and perform vulnerability testing on your home-grown applications prior to deployment.

What is a buffer overflow attack?


A buffer overflow is an exploit that takes advantage of a program that is waiting on a user's input. There are two main types of?buffer overflow attacks: stack based and heap based. Heap based attacks flood the memory space reserved for a program, but the difficulty involved with performing such an attack makes them rare. Stack-based buffer overflows are by far the most common and are the type I will focus on in this tip.
In a stack-based buffer overrun, the program being exploited uses a memory object known as a stack to store user input. Normally, the stack is empty until the program requires user input. At that point, the program writes a return memory address to the stack and then the user's input is placed on top of it. When the stack is processed, the user's input gets sent to the return address specified by the program.
However, a stack does not have an infinite potential size. The programmer who develops the code must reserve a specific amount of space for the stack. If the user's input is longer than the amount of space reserved for it within the stack, then the stack will overflow. This in itself isn't a huge problem, but it becomes a huge security hole when combined with malicious input.
For example, suppose a program is waiting for a user to enter his or her name. Rather than enter the name, the hacker would enter an executable command that exceeds the stack size. The command is usually something short. In a Linux environment, for instance, the command is typically EXEC("sh"), which tells the system to open a command prompt window, known as a root shell in Linux circles.
Yet overflowing the buffer with an executable command doesn't mean that the command will be executed. The attacker must then specify a return address that points to the malicious command. The program partially crashes because the stack overflowed. It then tries to recover by going to the return address, but the return address has been changed to point to the command specified by the hacker. Of course this means that the hacker must know the address where the malicious command will reside. To get around needing the actual address, the malicious command is often padded on both sides by NOP instructions, a type of pointer. Padding on both sides is a technique used when the exact memory range is unknown. Therefore, if the address the hacker specifies falls anywhere within the padding, the malicious command will be executed.
The last part of the equation is the executable program's permissions. As you know, most modern operating systems have some sort of mechanism to control the access level of the user who's currently logged on. Executable programs typically require a higher level of permissions than the user who's currently logged on, and are therefore run either in kernel mode or with permissions inherited from a service account. When a stack overflow attack runs the command found at the new return address, the program thinks it is still running. This means that the command prompt window that has been opened is running with the same set of permissions as the application that was compromised. Generally speaking, this often means that the attacker will gain full control of the operating system.

 Download your Full Reports for Buffer Overflow Attack


Solution :
1. Avoid using library files included with the compiler
Library files are commonly included with a programming language. If a hacker finds a weakness with a particular library file, any application that includes that particular library file also has the weakness. So if a hacker wants to exploit a home-grown application, he will often start by trying to exploit known weaknesses in commonly-used libraries.
Libraries are also inherently insecure. Although newer compilers are starting to include more securely-written library files, for the longest time libraries offered a quick-and-easy way to accomplish a task with little regard for secure coding. This was especially true of the C++ programming language. Programs coded in C++ that rely on the standard libraries are very susceptible to run-time errors, a dream come true for hackers looking for a buffer exploit.
2. Qualify all user input
To qualify all user input in home-grown applications, first make sure the input string is a valid length. For example, suppose your program is designed to accept 50 characters of text and add them to a database. If the user enters 75 characters, then they have entered more text than the database record can accommodate, and who knows what will happen next. User input should be designed so when a user enters a text string, the length of the string is compared against the maximum allowed input and truncated if necessary.
3. Filter potentially malicious input
Filtering is another good defense technique. For example, take a look at the ASP code below:
'Filter out HTML code, apostrophes and quotation marks from the user's input.
strNewString = Request.Form("Review")
strNewString = Replace(strNewString, "&", "& amp;")
strNewString = Replace(strNewString, "<", "& lt;")
strNewString = Replace(strNewString, ">", "& gt;")
strNewString = Replace(strNewString, "'", "`")
strNewString = Replace(strNewString, chr(34), "``")
The code above is used for an e-commerce Web site that I am currently developing. The idea is to filter out HTML code and characters that may cause problems with the database. HTML code uses the < and > characters to designate an HTML tag. To prevent users from embedding HTML code in their input, I am filtering out the greater than and less than sign.
In ASP code, the apostrophe, quotation mark and ampersand symbols are all reserved symbols. These reserved symbols can not be included within a user's input or they will cause the application to crash. For example, if someone used an apostrophe within a line of text that was to be committed to a database, the command would fail because ASP requires apostrophes around the text being committed to the database; ASP wouldn't know what to do with the user's apostrophe. To prevent this from happening, my code is searching the input string for an apostrophe and replacing it with the ` symbol.
4. Test applications
Qualifying and filtering user input goes a long way toward protecting you against buffer overrun attacks. But you still need to thoroughly test any application prior to deployment. Have a group of people go through the program with a fine-toothed comb and try to crash the program. Have them try entering long strings or reserved characters. If you have done a good job coding the application, it should hold up to the abuse. If the program does break, it's better to find out now than after the program has gone live.
Example :
The C programming language does not perform automatic bounds checking on arrays or pointers as many other languages do. In addition, the standard C library is filled with a handful of very dangerous functions.


strcpy(char *dest, const char *src)

May overflow the dest buffer

strcat(char *dest, const char *src)

May overflow the dest buffer

getwd(char *buf)

May overflow the buf buffer

gets(char *s)

May overflow the s buffer

[vf]scanf(const char *format, ...)

May overflow its arguments.

realpath(char *path, char resolved_path[])

May overflow the path buffer

[v]sprintf(char *str, const char *format, ...)

May overflow the str buffer.

The following example code contains a buffer overflow designed to overwrite the return address and skip the instruction immediately following the function call.
#include <stdio.h>
void manipulate(char *buffer) {
char newbuffer[80];
strcpy(newbuffer,buffer);
}
int main() {
char ch,buffer[4096];
int i=0;

while ((buffer[i++] = getchar()) != '\n') {};

i=1;
manipulate(buffer);
i=2;
printf("The value of i is : %d\n",i);
return 0;
}

 Download your Full Reports for Buffer Overflow Attack

Advertisement

© 2013 123seminarsonly.com All Rights Reserved.