StackGuard Effectiveness

 

 

Vulnerable Result Without Result With Result With

Program StackGuard Canary StackGuard MemGuard StackGuard

dip 3.3.7n root shell program halts program halts

elm 2.4 PL25 root shell program halts program halts

Perl 5.003 root shell program halts irregularly root shell

Samba root shell program halts program halts

SuperProbe root shell program halts irregularly program halts

umount 2.5k/libc 5.3.12 root shell program halts program halts

wwwcount v2.3 httpd shell program halts program halts

zgv 2.7 root shell program halts program halts

 

Here we illustrate StackGuard's effectiveness in thwarting stack smashing buffer overflow attacks. StackGuard is intended to thwart generic stack smashing attacks, even those that have not yet appeared. To simulate that, we sought out buffer overflow exploits, and tried them against their intended software targets, with and without protection from StackGuard. Table 1 summarizes these results.

The programs listed in Table 1 are conventionally installed as SUID root. If the attacker can get one of these programs to start a shell, then the attacker gets a root shell.

In each case, the experiment is to install the vulnerable program SUID root (SUID httpd for wwwcount) and attack it with the exploit. We then re-compile the program with the Canary variant of StackGuard, re-install the StackGuard-enhanced program as SUID root, and attack it again with the exploit. We did not alter the source code of any of the vulnerable programs at all, and StackGuard has no specific knowledge of any of these attacks. Thus this experiment simulates the effect of StackGuard defending against unknown attacks.

In all cases we have studied, both the Canary and the MemGuard variants of StackGuard stopped what would have been an attack that obtains a root shell. Several cases deserve special discussion:

umount 2.5k/libc 5.3.12:

The buffer overflow vulnerability is actually in libc, and not in umount. Simply re-compiling umount with either variant of StackGuard does not suffice to stop the attack. However, when libc is also compiled using StackGuard (either variant) then the attack is defeated. Thus for full protection, either the system shared libraries must be protected with StackGuard, or the privileged programs must be statically linked with libraries that are protected with StackGuard.

SuperProbe:

This attack does not actually attack the function return address. Rather, it over-writes a function pointers in the program that is allocated on the stack. The Canary variant stopped the attack by perturbing the layout of the stack, but an adjusted attack produced a root shell even with Canary protection. The MemGuard variant stopped the attack because a return address was in the way of the buffer overflow. Proper treatment of this kind of attack requires an extension to StackGuard, as described in Section 5.4.

Perl:

Like SuperProbe, the Perl attack does not attack the function return address. This attack over-writes data structures in the global data area, and thus is not properly a ``stack smashing'' attack. Permutations in the alignment of the global data area induced by the StackGuard's vector of canary values prevented the attack from working, but a modified form of the attack produced a root shell despite Canary protection. MemGuard had no effect on the attack.

Samba, wwwcount:

These buffer overflow vulnerabilities were announced after the StackGuard compiler was developed, yet the StackGuard-enhanced versions of these programs were not vulnerable to the attacks. This illustrates the point that StackGuard can effectively prevent attacks even against unknown vulnerabilities.

We would like the list of programs studied to be larger. Two factors limit this kind of experimentation:

Obtaining the Exploit:

It is difficult to obtain the exploit code for attacking programs. Security organizations such as CERT are reluctant to release exploits, and thus most of these exploits were obtained either from searching the web, or from the bugtraq mailing list [16].

Obtaining Vulnerable Source Code:

Buffer overflow attacks exploit specific, simple vulnerabilities in popular software. Because of the severe security risks posed, and the ease of patching the individual vulnerability, new releases appear soon after the vulnerability is publicized. Moreover, the vulnerability is often not publicized until it can be announced with a patch in hand. The older vulnerable source code is often not easily available. We have begun archiving source code versions, so that we will be able to add experiments as new vulnerabilities appear.