Re: StackGuard: Automatic Protection From Stack-smashing Attacks

Crispin Cowan (crispin@CSE.OGI.EDU)
Fri, 19 Dec 1997 13:59:55 -0800

Steve Bellovin writes:
> Yup. In fact, the first buffer overflow security problem I know of
> was in an early version of UNIX -- 6th Edition, I think; possibly 5th --
> where the 'logged in' flag in login.c was adjacent to an input buffer...

It is correct that StackGuard only protects the return address. The
Future Work section of the paper describes some approaches to
protecting other data structures. I do not want to over-state
StackGuard's present capabilities; it does not completely eliminate
vulnerability to buffer overflow attacks. It *does* stop *most* of the
attacks that I have been able to obtain scripts and vulnerable source
code for that were posted to Bugtraq in the last year. The notable
exception is the Perl 5.003 vulnerability, precisely because that
attack does not affect the return address.

I also agree wtih Tim Newsham that hygenic code that doesn't contain
any buffer overflow vulnerabilities is a preferable solution. But
given that the rate of reporting of buffer overflow vulnerabilities is
not abating, that day seems a long way off. In the mean time,
StackGuard provides several key benefits:

1. It stops many of the existing attacks
2. It stops many of the future unknown attacks that attack the
return address
3. It *tells* you when someone tries to smash your stack.
This lets you either report the problem to the program's
author, or go fix it yourself. So StackGuard helps to move
us towards cleaner code.

Regarding guessing the canary value, it is really hard to brute-force a
guess at the canary value. The canary is randomly chosen at exec time;
if you make a repeated attack guessing a new value, the value will have
changed between guesses. The value is 32 bits. So if you made 4
billion attacks, you would get it right once with probability
approaching one, but you are not guaranteed to get it even then.

It is more plausible to use Newsham's technique to get the program to
reveal the canary value, but that only applies where the additional
vulnerability of a buffer that can be used to get at the canary word
exists. Also note that there is a separate canary value per function,
so a canary-access buffer vulnerability in one function does not help
you to smash a different function.

Thanks very much for your comments.

Crispin Cowan, Research Assistant Professor of Computer Science
Oregon Graduate Institute | Electronically:
Department of Computer Science | analog: 503-690-1265
PO Box 91000 | digital:
Portland, OR 97291-1000 | URL:
Knowledge is to Wisdom as Data is to Code