Re: StackGuard: Automatic Protection From Stack-smashing Attacks

From: Crispin Cowan (crispinat_private)
Date: Fri Dec 19 1997 - 13:59:55 PST

  • Next message: Ivan Nejgebauer: "Xotpcalc, version 1.0"

    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: crispinat_private
    Portland, OR 97291-1000        | URL:     http://www.cse.ogi.edu/~crispin/
                    Knowledge is to Wisdom as Data is to Code
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:37:04 PDT