Stack-smashing protection
|
|
Stack-smashing protection is a technique of detecting buffer overflows as they occur and preventing them from becoming serious computer security vulnerabilities. There have been several implementations of stack-smashing protection, two of the most common being StackGuard and ProPolice.
| Contents |
How it works
Stack-smashing 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 imposes a negligible performance impact, as shown by the Immunix StackGuard benchmarks (http://immunix.org/StackGuard/performance.html), while giving the benefit of preventing an entire class of attacks.
An example
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; /*Integer pointer*/
char c[10]; /*character array*/
char d[3];
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 13 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 can be made to address any position in memory, causing a read from or a write to any arbitrary address. By overwriting RETA, the function can be made to execute other code, either existing functions (ret2libc) or code written into the stack during the overflow, either before or after RETA.
In a nutshell, mistaken handling of c and d, such as the unbounded strcpy() calls above, may allow an attacker to control a program if he is able to influence the values assigned to c and d directly. The goal of stack-smashing protection is to address this issue in the least intrusive way possible. This is done by removing what can be out of harms way; and by placing a sort of tripwire, or canary, inbetween the buffer and whatever else is left.
Stack-smashing protection is a change to the compiler; and 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 first thing that would occur would be that the above function's automatic variables would be rearranged to create less of a danger: arrays c and d would be allocated first in the stack frame, which would place integer a and integer pointer b before them in memory. This is illustrated in the stack frame below.
(b...)(a...)(d..)(c.........)(CTLI)(RETA)
As it is impossible to move CTLI or RETA without breaking the produced code, another tactic must be employed. An extra piece of information, called a "canary" (CNRY), is placed after the buffers in the stack frame. When the buffers are overflowed, the canary value must be changed; thus, to effectively execute an attack on the program, an attacker must leave definite indication of his attack. The stack frame looks as below.
(b...)(a...)(d..)(c.........)(CNRY)(CTLI)(RETA)
At the end of every function, there is a machine instruction that causes execution to continue from the memory address indicated by RETA. Before this instruction is executed, a check is made against CNRY to ensure that it has not been altered. If CNRY does not pass the check, program execution is ended immediately. In essence, both serious attacks and harmless programming bugs result in a program crash.
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 can guess the canary, and knows that it's there, he may simply copy over it with itself. This is highly implausible in most situations.
It may be noted that the position of the canary is implementation specific; but it is always between the buffers and the data that needs to be protected. Varied positions have varied benefits.
Canaries
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, it will clobber the canary, making the overflow evident.
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
Terminator Canaries are based on the observation that most buffer overflows and stack smash 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 stack-smashing protection, an attacker could potentially overwrite the canary and control information, then go back and write a shorter overflow to fix the canary. This is only effective in rare cases where double-overflows are possible.
Random canaries
Random canaries are randomly generated, usually from an entropy gathering daemon, so an attacker doesn't know what it is. It is not usually 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 stack-smashing 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
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.
Things stack-smashing protection cannot protect
Stack-smashing protection is unable to protect against certain forms of attack. For example, it cannot protect against buffer overflows in heap; that would be left to heap smash protection.
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.
There is no sane way to alter the structure of 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 be malloc()ed or new[]ed pointers.
Implementations
StackGuard is suggested for implementation in gcc according to the GCC 2003 Summit Proceedings and the StackGuard homepage (http://immunix.org/stackguard.html); however, gcc uses neither StackGuard nor ProPolice as of 3.3.3. Gentoo Linux uses ProPolice according to gcc -v:
gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)
StackGuard as of yet only exists as patches for gcc versions up to 2.95.
ProPolice is implemented for gcc as a patch, up to gcc version 3.4.0. The patch is used in Gentoo Linux and OpenBSD. Stack-smashing protection can be attained by adding -fstack-protector to the gcc command line, or enabled by default if the appropriate patches are applied.
See also
External links
- Citations from CiteSeer (http://citeseer.ist.psu.edu/cis?q=stack+smash+protection)
- The GCC 2003 Summit Proceedings (http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf)
- Smashing the Stack for Fun and Profit (http://www.phrack.org/show.php?p=49&a=14)
- ProPolice official home (http://www.research.ibm.com/trl/projects/security/ssp/)
- Immunix StackGuard Homepage (http://immunix.org/stackguard.html)