Bugtraq mailing list archives
Re: StackGuard: Automatic Protection From Stack-smashing Attacks
From: crispin () CSE OGI EDU (Crispin Cowan)
Date: 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 ----- Crispin Cowan, Research Assistant Professor of Computer Science Oregon Graduate Institute | Electronically: Department of Computer Science | analog: 503-690-1265 PO Box 91000 | digital: crispin () cse ogi edu Portland, OR 97291-1000 | URL: http://www.cse.ogi.edu/~crispin/ Knowledge is to Wisdom as Data is to Code
Current thread:
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Steve Bellovin (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Crispin Cowan (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Kragen (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Tim Newsham (Dec 19)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Crispin Cowan (Dec 19)
- Linux vsyslog() overflow Solar Designer (Dec 20)
- Re: Linux vsyslog() overflow Dann Lunsford (Dec 22)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Mark Whitis (Dec 30)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Ranaur the Elven Warlock (Dec 30)
- Apache memory/process management. MichaĆ Zalewski (Dec 31)
- Re: Apache memory/process management. Dean Gaudet (Dec 31)
- Re: StackGuard: Automatic Protection From Stack-smashing Attacks Crispin Cowan (Dec 19)