Buffer overflow protection refers to various techniques used during software development to enhance the security of executable programs by detecting buffer overflows on stack-allocated variables as they occur and preventing them from becoming serious security vulnerabilities. There have been several implementations of buffer overflow protection.
This article deals with stack-based overflow; similar protections also exist against heap-based overflows, but they are implementation-specific.
Contents |
Typically, buffer overflow protection modifies the organization of data in the stack frame of a function call to include a "canary" value which, when destroyed, shows that a buffer preceding it in memory has been overflowed. This gives the benefit of preventing an entire class of attacks. According to some software vendors, the performance impact of these techniques is negligible.
Canaries or canary words are known values that are placed between a buffer and control data on the stack to monitor buffer overflows. When the buffer overflows, the first data to be corrupted will be the canary, and a failed verification of the canary data is therefore an alert of an overflow, which can then be handled, for example, by invalidating the corrupted data.
The terminology is a reference to the historic practice of using canaries in coal mines, since they would be affected by toxic gases earlier than the miners, thus providing a biological warning system.
There are three types of canaries in use: Terminator, Random, and Random XOR. Current versions of StackGuard support all three, while ProPolice supports Terminator and Random canaries.
Terminator Canaries use the observation that most buffer overflow attacks are based on certain string operations which end at terminators. The reaction to this observation is that the canaries are built of NULL terminators, CR, LF, and -1. The undesirable result is that the canary is known. Even with the protection, an attacker could potentially overwrite the canary with its known value, and control information with mismatched values, thus passing the canary check code, this latter being executed soon before the specific processor return-from-call instruction.
Random canaries are randomly generated, usually from an entropy-gathering daemon, in order to prevent an attacker from knowing their value. Usually, it is not logically possible or plausible to read the canary for exploiting; the canary is a secure value known only by those who need to know it—the buffer overflow protection code in this case.
Normally, a random canary is generated at program initialization, and stored in a global variable. This variable is usually padded by unmapped pages, so that attempting to read it using any kinds of tricks that exploit bugs to read off RAM cause a segmentation fault, terminating the program. It may still be possible to read the canary, if the attacker knows where it is, or can get the program to read from the stack.
Random XOR Canaries are Random Canaries that are XOR scrambled using all or part of the control data. In this way, once the canary or the control data is clobbered, the canary value is wrong.
Random XOR Canaries have the same vulnerabilities as Random Canaries, except that the 'read from stack' method of getting the canary is a bit more complicated. The attacker must get the canary, the algorithm, and the control data to generate the original canary for re-encoding into the canary he needs to use to spoof the protection.
In addition, Random XOR Canaries can protect against a certain type of attack involving overflowing a buffer in a structure into a pointer to change the pointer to point at a piece of control data. Because of the XOR encoding, the canary will be wrong if the control data or return value is changed. Because of the pointer, the control data or return value can be changed without overflowing over the canary.
Although these canaries protect the control data from being altered by clobbered pointers, they do not protect any other data or the pointers themselves. Function pointers especially are a problem here, as they can be overflowed into and will execute shellcode when called.
Stack-smashing protection is unable to protect against certain forms of attack. For example, it cannot protect against buffer overflows in the heap.
StackGuard and ProPolice cannot protect against overflows in automatically allocated structures which overflow into function pointers. ProPolice at least will rearrange the allocation order to get such structures allocated before function pointers. A separate mechanism for pointer protection was proposed in PointGuard[1] and is available on Microsoft Windows.[2]
There is no sane way to alter the layout of data within a structure; structures are expected to be the same between modules, especially with shared libraries. Any data in a structure after a buffer is impossible to protect with canaries; thus, programmers must be very careful about how they organize their variables and use their structures. Structures with buffers should either be malloc()ed or obtained with new.
StackGuard was released for GCC in 1997, and published at USENIX Security 1998. StackGuard is an extension to GCC that provides buffer overflow protection. It was invented by Crispin Cowan, first implemented as a zero canary in the i386 backend for GCC 2.7.2.2 by Aaron Grier, and verified by Peat Bakke. Perry Wagle continued maintenance of StackGuard for the Immunix project, and implemented the Terminator, Random, and Random XOR canaries.
StackGuard was made available as a standard part of the Immunix Linux distribution from 1998 to 2003, providing both Red Hat-compatible binary RPMs and patched GCC sources from GCC 2.7.2.3 through 2.96.
StackGuard was suggested for implementation in GCC according to the GCC 2003 Summit Proceedings and the StackGuard homepage; however, gcc 3.x offers no official buffer overflow protection, and the SSP concept below has been adapted for GCC 4.1 instead.
The "Stack-Smashing Protector" or SSP, also known as ProPolice, is an enhancement of the StackGuard concept written and maintained by Hiroaki Etoh of IBM. Its name derives from the word propolis. ProPolice differs from StackGuard in three ways:
It was implemented as a patch to GCC 3.x; a less intrusive reimplementation is included in the GCC 4.1 release. Currently, SSP is standard in OpenBSD, FreeBSD (since 8.0), Ubuntu (since 6.10 [3]), Hardened Gentoo (in gcc 4.x by default since October 2010, previously also in gcc 3.x) and DragonFly BSD. It is also available in NetBSD (enabled by default on x86), Debian and Gentoo, disabled by default.
By default, stack-smashing protection can be attained by adding the -fstack-protector flag for string protection, or -fstack-protector-all for protection of all types. On some systems, as under OpenBSD, ProPolice is enabled by default, and the -fno-stack-protector flag disables it. With GCC 4.1 and above the array size threshold for stack-smashing protection to be enabled can be tuned with --param ssp-buffer-size=....
The compiler suite from Microsoft also implements buffer overflow protection since version 2003. /GS is enabled by default.[4] Use /GS- if the protection must explicitly be disabled.
Stack-smashing protection can be turned on by the compiler flag -qstackprotect.[5]
Invented by Mike Frantzen, StackGhost is a simple tweak to the register window spill/fill routines which makes buffer overflows much more difficult to exploit. It uses a unique hardware feature of the Sun Microsystems SPARC architecture (that being: deferred on-stack in-frame register window spill/fill) to detect modifications of return pointers (a common way for an exploit to hijack execution paths) transparently, automatically protecting all applications without requiring binary or source modifications. The performance impact is negligible, less than one percent. The resulting gdb issues were resolved by Mark Kettenis two years later, allowing enabling of the feature. Following this event, the StackGhost code was integrated (and optimized) into OpenBSD/SPARC.
Normal buffer allocation for x86 architectures and other similar architectures is shown in the buffer overflow entry. Here, we will show the modified process as it pertains to StackGuard.
When a function is called, a stack frame is created. A stack frame is built from the end of memory to the beginning; and each stack frame is placed on the top of the stack, closest to the beginning of memory. Thus, running off the end of a piece of data in a stack frame alters data previously entered into the stack frame; and running off the end of a stack frame places data into the previous stack frame. A typical stack frame may look as below, having a Return Address (RETA) placed first, followed by other control information (CTLI).
(CTLI)(RETA)
In C, a function may contain many different per-call data structures. Each piece of data created on call is placed in the stack frame in order, and is thus ordered from the end to the beginning of memory. Below is a hypothetical function and its stack frame.
int foo() { int a; /*integer*/ int *b; /*pointer to integer*/ char c[10]; /*character array*/ char d[3]; b = &a; /*initialize b to point to location of a*/ strcpy(c,get_c()); /*get ''c'' from somewhere, write it to ''c''*/ *b = 5; /*the data at the point in memory ''b'' indicates is set to 5*/ strcpy(d,get_d()); return *b; /*read from ''b'' and pass it to the caller*/ }
(d..)(c.........)(b...)(a...)(CTLI)(RETA)
In this hypothetical situation, if more than ten bytes are written to the array c, or more than 3 to the character array d, the excess will overflow into integer pointer b, then into integer a, then into the control information, and finally the return address. By overwriting b, the pointer is made to reference any position in memory, causing a read from an arbitrary address. By overwriting RETA, the function can be made to execute other code (when it attempts to return), either existing functions (ret2libc) or code written into the stack during the overflow.
In a nutshell, poor handling of c and d, such as the unbounded strcpy() calls above, may allow an attacker to control a program by influencing the values assigned to c and d directly. The goal of buffer overflow protection is to detect this issue in the least intrusive way possible. This is done by removing what can be out of harms way and placing a sort of tripwire, or canary, after the buffer.
Buffer overflow protection is implemented as a change to the compiler. As such, it is possible for the protection to alter the structure of the data on the stack frame. This is exactly the case in systems such as ProPolice. The above function's automatic variables are rearranged more safely: arrays c and d are allocated first in the stack frame, which places integer a and integer pointer b before them in memory. So the stack frame becomes
(b...)(a...)(d..)(c.........)(CTLI)(RETA)
As it is impossible to move CTLI or RETA without breaking the produced code, another tactic is employed. An extra piece of information, called a "canary" (CNRY), is placed after the buffers in the stack frame. When the buffers overflow, the canary value is changed. Thus, to effectively attack the program, an attacker must leave definite indication of his attack. The stack frame is
(b...)(a...)(d..)(c.........)(CNRY)(CTLI)(RETA)
At the end of every function there is an instruction which continues execution from the memory address indicated by RETA. Before this instruction is executed, a check of CNRY ensures it has not been altered. If the value of CNRY fails the test, program execution is ended immediately. In essence, both serious attacks and harmless programming bugs result in a program abort.
The canary technique adds a few instructions of overhead for every function call with an automatic array, immediately before all dynamic buffer allocation and after dynamic buffer deallocation. The overhead generated in this technique is not significant. It does work, though, unless the canary remains unchanged. If the attacker knows that it's there, he may simply copy over it with itself. This is usually difficult to arrange intentionally, and highly improbable in unintentional situations.
The position of the canary is implementation specific, but it is always between the buffers and the protected data. Varied positions and lengths have varied benefits.