Buffer overflow |
In computer programming, a buffer overflow is an anomalous condition where a program somehow writes Data beyond the allocated end of a buffer in computer storage. Buffer overflows usually arise as a consequence of a computer bug and the improper use of languages such as C programming language or C plus plus that are not memory-safe . One consequence of the overflow is that valid data can be overwritten as a result. Buffer overflows are also a commonly exploited computer security risk — since program control data often sits in the memory areas adjacent to data buffers, by means of a buffer overflow condition, the computer can be made to execute arbitrary (and potentially malicious) code that is fed to the buggy program as data.
=Security ramifications=
A program which takes advantage of a vulnerability to subvert another program s security is called an exploit (computer science) and is usually intended to gain access to Superuser or otherwise escalated privileges. A buffer overflow exploit works by feeding the program specially crafted input content that is designed to overflow the allocated data storage buffer and change the data that follows the buffer in computer storage.
For example, imagine a hypothetical program that executes with superuser privileges in order to perform some system administrative function such as changing a user password. If the program fails to ensure that the length of the new password entered is equal to or smaller than the data buffer allocated for its storage, then any overflow data will simply be written over whatever happens to be after the data buffer. If this post-buffer area is executable code, a malicious user can insert machine language instructions that can perform any function normally requiring root privileges — add users, delete users, change passwords, alter or delete any file, etc.
Properly written programs ought to check the length of input data, to ensure that it is not larger than the allocated data buffer, but this is frequently overlooked, especially by novice programmers. Buffer overflows are most easily exploited when the data buffer is in the program s function stack, since this can lead directly to an alteration of the program s execution path.
Determining the exploitability of a buffer overflow vulnerability can be difficult, even for experienced computer programmer, since it involves a lot of high and low level knowledge of the computer architecture internals and the target program. Overflows of as little as a single byte beyond the end of a buffer have proved to be exploitable.
Generally, the buffer overflow problem is caused by careless programming. Avoiding them is still a manual process as most formal verification systems have yet proven unattainable in modern programming languages. Buffer overflows are common only in programs written in relatively low-level programming languages, such as assembly language, C programming language, and C plus plus which require the programmer to manually manage the size of allocated memory. This does not make C a bad language, as the errors are more often caused by bad programming rather than bad language choice. Many programming languages such as Java programming language and Lisp programming language manage memory allocation automatically, and use a combination of run time checking and static analysis to make it difficult or impossible to code a buffer overflow bug. Perl provides for automatic resizing of the arrays to avoid buffer overflows. However, runtime systems and libraries for such languages may still occasionally have buffer overflows due to internal implementation errors in these checking systems. In Windows systems, several software options are available to refuse the execution of buffer overflow code, once the overflow has occurred, including Windows XP SP2 s DEP, OSsurance, and Anti-Execute.
=Technical rundown=
==Description==
A more technical view of this would be best explained by using C or C++ to demonstrate a stack based buffer overflow. Heap_overflow are another danger to consider. This example is based around x86 architectures, but works for many others.
When a dynamic buffer or automatic array is allocated in a function, it is allocated at function call time on the stack. Writing data to the buffer can write beyond it on the stack. Also, the stack grows from bottom up (or from right to left, depending on perspective). Here, (DATA) (DATA) (...) represents the existing stack, and (NEWDATA) is some new value the CPU has pushed onto the stack:
(NEWDATA)(DATA)(DATA)(...)
When a C program executes a subroutine, it pushes the return address onto the stack, so the subroutine knows where to return control to when it has finished:
(ADDR)(DATA)(DATA)(...)
When a dynamic buffer is allocated, the stack grows left by however big the buffer is. So, if a function starts with a char a[10] declaration, the result is:
(.a.........)(ADDR)(DATA)(DATA)(...)
At the end of the function, the buffers are deallocated, everything pushed is popped, and a RET operation is called. This pops the return address off the stack and jumps there, shifting program control back to wherever the subroutine was called from.
Suppose that 10 byte buffer is intended to hold user input (a new password, for example). If the program fails to specifically check the number of characters the user has entered, and writes 14 bytes to the buffer, the extra data will clobber the return address, overwriting part of it with the extra data. This changes where program control will go to continue execution when the subroutine has finished.
If the user is not malicious and enters more than 10 characters, the extra data will effectively be random, and will probably end up making the return address point to an area in memory which is not under the control of the currently executing program, causing a segmentation fault on Unix architectures (or an analogous error on other operating systems) when the RET instruction attempts to jump control there.
If a technically inclined user is malicious, they can ensure that the extra data does indeed point to a valid memory address, causing program control to be shifted to this location of their choosing, and potentially executing whatever arbitrary code the user has caused to be in that location with whatever privileges the currently executing program has.
==Example==
The following is C programming language source code. Once compiled, the program can be used to generate buffer overflow errors. The first command-line argument is taken as the text with which to fill the buffer.
/* overflow.c - demonstrates the buffer overflow process */
#include #include
int main(int argc, char *argv[]) { char buffer[10]; if(argc < 2) { fprintf(stderr, USAGE: %s string , argv[0]); return 1; } strcpy(buffer, argv[1]); return 0; }
After compiling the program, try it with a few test cases. Strings of 10 or fewer characters will not cause a buffer overflow. Strings of 11 or more characters will cause an overflow, however they may not result in a segmentation fault.
This program could be rewritten as follows, using strncpy effectively.
/* better.c - demonstrates how to fix the problem */
#include #include #define BUFFER_SIZE 10
int main(int argc, char *argv[]) { char buffer[BUFFER_SIZE]; if(argc < 2) { fprintf(stderr, USAGE: %s string , argv[0]); return 1; } strncpy(buffer, argv[1], BUFFER_SIZE - 1); buffer[BUFFER_SIZE - 1] = ; return 0; }
=Prevention=
Various techniques have been used to make buffer overflows less likely.
==Intrusion-detection software==
The use of Intrusion-detection system can detect remote attempts to use buffer overflows. Since most buffer overflows contain a long array of instructions that have No OPeration (NOP s) or (NOOP), the IDS just has to block all incoming packets containing a large number of consecutive NOP s. This is generally ineffective, as these arrays can be written using a large variety of Assembly_language instructions. Recently, Black hat have begun to use alphanumeric code, polymorphic code, and self-modifying code shellcodes to slip through these IDS systems.
See:
==Stack-smashing protection==
Stack-smashing protection is used to detect the most common buffer overflows by checking that the stack (computing) has not been altered when a function returns. If it has been altered, the program exits with a segmentation fault.
Two such systems are StackGuard and ProPolice, both of which are extensions to gcc. As of gcc-4.1-stage2 ProPolice (which appears to have obsoleted StackGuard) patch seems to have been incorporated into the mainline distribution. Gentoo Linux Linux and OpenBSD supply ProPolice by default with gcc.
Putting the return address on the data stack makes it easy for a buffer overflow to lead to executing arbitrary code. In theory, gcc could be patched to place the return address on a return stack completely separate from the data stack, reminiscent of the Forth programming language. This is not a complete solution to buffer overflows however, as other stack data may need to be protected.
See:
==Executable space protection for Unix / Linux systems==
Protecting the executable space may soften the blow of buffer overflow exploits by making most of their operations impossible. This is done by randomizing the address space (ASLR) and making sure memory is not writable and executable. A non-executable stack will stave off most shellcode exploits.
Two patches for the Linux kernel that accomplish this are PaX and Exec Shield. Neither of these are yet included in the mainstream kernel. OpenBSD since 3.3 has included a system called W xor X, which provides executable space control as well.
Note that this manner of protection will not prevent stack smashing; however, it will often prevent the payload from being successfully delivered. The program will not be able to inject shellcode into non-writable memory, such as the existing code segments. It also will not be able to execute non-executable memory, such as the stack or the heap.
ASLR will make ret2libc type attacks a very difficult guessing game. They are still possible in a controlled environment, or if the attacker guesses correctly.
Some CPUs such as Sun s Sparc, Transmeta s Efficeon, and newer 64-bit Intel and AMD x86 processors prevent code from being executed on areas of memory flagged with a special NX bit. AMD call their solution NX, derived from No eXecute and Intel call theirs XD, after eXecute Disabled.
==Executable space protection for Windows systems==
Due to the Windows system s nature the portation of similar protection methods as found as add ons on the linux/unix platform took slightly longer. Today, Windows customers can choose from a wide variety of MS and 3rd party Executable Space Protection (ESP) solutions providing features aimed at the prevention of execution of malicious code.
Microsoft has recently introduced their ESP solution named DEP (Data Execution Prevention) with Service Pack 2 for XP and Service Pack 1 for Windows 2003. DEP relies on a hardware extension provided by Intel/AMD built on top of PAE (Page Addressing Extensions). PAE was initially created to overcome the 4GB limit resulting from 32 bit wide memory management. It effectively increases the affected data structures to cover additional bits in order to be capable of addressing beyond the 4GB boundary. Furthermore, the extended data structures contain a special NX bit, that is not used otherwise during normal PAE mode (reserved bit). The NX bit is used to mark pieces of data (particularly the stack and the heap) as readable but non executable, thus preventing data on an overflowed stack from being executed. The NX flag can be enabled and disabled per application, and it s only currently available on some 64 bit CPUs (regardless of the OS being 32 bits or 64 bits). Microsoft software DEP takes another approach, preventing the so-called SEH exploit (using a buffer overflow to overwrite an exception handler s address pointer in order to take control). Microsoft software DEP does not provide non executable code pages but SEH exploit protection only!
Besides that, Microsoft has introduced a stack protection mechanism with Windows Server 2003 which detects overwritten stack memory by marking the stack with a so-called canary that gets verified at a later time. If the (random) canary has changed the stack was overwritten.
There are multiple 3rd party solutions providing non-executable data pages and/or ASLR on the market today. The PAX website maintains a list of Windows-related solutions: http://pax.grsecurity.net
==Use of safe libraries==
The problem of buffer overflows is commonly manifest in the C programming language and C plus plus languages because they expose low level representational details of buffers as containers for datatypes. Buffer overflows are thus avoided by maintaining a high degree of correctness in code which performs buffer management. Well written and tested abstract data type libraries which centralize and automatically perform buffer management and include overflow testing is one engineering approach to reduce the occurrence of buffer overflows. The two main building block data types in these languages in which buffer overflows are commonly manifest are strings and arrays, thus use of string and list-like data structure libraries which have been architected to avoid and/or detect buffer overflows provide the vast majority of the necessary coverage.
See:
==Choice of programming language==
The choice of programming language can have a profound effect on the existence of buffer overflows. As of 2005, the most popular languages generally are C programming language and its derivative, C plus plus. Languages such as these do not check that data, when written to an array (the implementation of a buffer), is within the assumed boundaries of the array. Other programming languages differ in this regard, sending a warning or raising an exception handling when such a data assignment is made. Examples of such languages are Java programming language and Pascal programming language and its descendants such as Ocaml, Modula-2, Oberon programming language, and Ada programming language, and also dialects of C such as Cyclone programming language and CCured. There are many other such languages.
Part of the original rationale for choosing C is that it is fast, in part because it does not take processor time to do such boundary checking; however, tests have shown that the amount of time added in checking array boundaries does not usually represent a burdensome overhead. In an era of fast processors (relative to the most common tasks, c. 2004), that original tradeoff of speed versus safety might be reconsidered. Such language features remain an ongoing debate among some within the software design community.
=Notable buffer overflow exploits=
In 1988, the Morris worm used a buffer overflow in a Unix program called finger protocol to propagate itself over the Internet. Even after this incident, buffer overflows were virtually ignored as security issue. Later, in 1995, Thomas Lopatic independently reinvented the buffer overflow and published his findings on the Bugtraq security mailing list, which caused a wave of new security relevant buffer overflows to be found. In 1996, Elias Levy (aka Aleph One) published in Phrack magazine the paper Smashing the Stack for Fun and Profit , a step-by-step introduction to exploiting stack-based buffer overflow vulnerabilities, which caused a wave of new buffer overflow exploits to be written. Then, in 2001, the Code Red worm Buffer overflow worm sent specially crafted packets to machines executing Microsoft Internet Information Services (IIS) 5.0, yielding full administrative privileges to the exploit since IIS5 didn t drop administrative privileges after binding to port 80. Following in 2003, the SQLSlammer worm compromised machines running Microsoft SQL server 2000 by sending specially crafted packets to those machines and allowing execution of Arbitrary code.
=See also=
*application firewall *Buffer management *computer security *heap overflow *Memory debugger *Pointer swizzling *Secure operating systems *Security focused operating systems *shellcodes *Software testing *SPlint *Static code analysis *strcpy *strcat
=External links=
*[http://www.sys-manage.com/index10.htm Buffer Overflow Protection Solution for Microsoft Windows(R) Operating Systems] *[http://www.bestpricecomputers.ltd.uk/guides/NX-XD.htm Hardware solutions, execute disabled, AMD s NX and Intel s XD solutions] *[http://www.sans.org/rr/paper.phpid=386 SANS: inside the buffer overflow attack] *[http://community.corest.com/~gera/InsecureProgramming/ Insecure Programming by Example] by Gerardo Richarte *[http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/buffer-overflow.html Secure Programming for Linux and Unix HOWTO: Avoid Buffer Overflow] by David A. Wheeler *[http://www-106.ibm.com/developerworks/linux/library/l-sp4.html Secure programmer: Countering buffer overflows] *[http://www.phrack.org/phrack/49/P49-14 Smashing The Stack For Fun And Profit] by Aleph One *[http://www.cse.ogi.edu/~crispin Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade ] by Crispin Cowan, Perry Wagle, Calton Pu, Steve Beattie, and Jonathan Walpole discusses the Stackguard approach to countering stack-smashing attacks. *[http://www.enderunix.org/documents/eng/bof-eng.txt Buffer Overflows Demystified] by murat *[http://www.wired.com/wired/archive/11.07/slammer.html Wired 11.07: Slammed!] A detailed explanation of the Slammer worm code, and how it exploits buffer overflow. *[http://www.cultdeadcow.com/cDc_files/cDc-351/index.html The Tao of Windows Buffer Overflow ]|
|