Buffer overflow: Meaning (information, definition, explanation, facts)

A buffer overflow is a type of computer bug. When the length limitation of a space reserved for data — a buffer — is not properly enforced, the buffer "overflows". Input data is written to the buffer and, if it is longer than the buffer size, the space beyond the end of the buffer is overwritten. This might corrupt other data, or more seriously, the program code.

Buffer overflows and computer security

Buffer overflow bugs are frequently security vulnerabilities. A program which takes advantage of a vulnerability to subvert another program's security is called an exploit and is usually intended to gain access to superuser privileges. A buffer overflow exploit works by feeding the program with specially crafted content designed to change the data that follows the buffer in memory. Buffer overflows are most easily exploited when the buffer is in the program stack, since this can lead directly to an alteration of the program's execution path. Another term for a buffer overflow attack is a "Stack Smash Attack."

Determining the exploitability of a buffer overflow vulnerability can be difficult even for experienced programmers, since it involves a lot of high and low level knowledge of the 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, and C++. Many programming languages use a combination of run time checking and static analysis to make it difficult or impossible to code a buffer overflow bug. However, runtime systems and libraries for such languages may occasionally have buffer overflows.

A more technical view of this would be best exampled with C or C++. This is based around x86 architectures, but works for many others.

Basically, when a dynamic buffer or automatic array is allocated in a function, it is allocated at function call time on the stack. So, 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. So, when the CPU pushes a value, i.e. a return address, it goes on the stack:

(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]', 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.

If a program allocates a 10 byte character buffer, and writes 14 bytes to it, it will clobber the return address. This changes where the program will go to continue execution.

For a basic analogy, let's try putting information about you on a small card, with a small fixed space for name and address. Here is the card:

Name: _____ Address: _______________________________

Now let's say your name is "Super Big Long Name Man the Third of Whales." You write it on the card, even though it is too big to fit the space, overwriting the "Address:" field.

Name: Super Big Long Name Man the Third of Whales____

Your address here is "ame Man the Third of Whales" because of this. Now your important mail goes to the wrong address.

IDS

The use of Intrusion Detection Software can detect remote attempts to use buffer overflows. Since most buffer overflows contains a long array of instructions that have No OPeration (NOP's)or(NOOP's), the IDS just has to block all incoming packets containing a large number of consecutive NOP's. Recently, crackers have begun to use alphanumeric, polymorphic, and self-modifying shellcodes to slip through the IDS.

C

Various techniques have been used to make buffer overflows in C programs less likely. Systems such as StackGuard and ProPolice provide protection against the most common techniques for exploiting buffer overflows by checking that the stack has not been altered when a function returns.

Stack smash protection

Stack Smash Protection is a quick fix that has the basic goal of turning exploits into almost harmless segfault bugs. When a stack smash is triggered, SSP will detect it, and then exit the program with a segmentation fault.

In ProPolice patched versions of gcc, the -fstack-protector and -fstack-protector-all switches for gcc compile code to include a few references to __guard@glibc and __stack_smash_handler@glibc around stack based buffers. The StackGuard patch is also for gcc.

As of gcc-3.3.3, neither patch seems to be used in mainline gcc. Gentoo Linux and OpenBSD supply ProPolice by default with gcc.

Please see the StackGuard and ProPolice entries for more specific details.

Executable space protection

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 included in the mainstream kernel.

OpenBSD since 3.3 has included a system called W^X, which provides executable space control as well.

Note that this manner of protection will not prevent stack smashes; however, it will often prevent the payload from being successfully delivered. The program won't be able to inject shellcode into non-writable memory, such as the existing code segments. It also won't 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, but they're still possible in a controlled environment, or if the attacker guesses correctly.

In 1989, the Morris worm used a buffer overflow in a Unix program called finger 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.