Re: Buffer overflow prevention

From: Crispin Cowan (crispinat_private)
Date: Mon Aug 18 2003 - 13:43:05 PDT

  • Next message: Nicholas Weaver: "Re: msblast.d and a review of defensive worms"

    Mark Tinberg wrote:
    
    >Thank you for bringing up this point.  ISTM that expecting all
    >security-critical userspace code to be audited to perfection as a
    >prerequisite to system security is foolish.  No one, not even the most
    >intelligent and knowledgeable security guru can write every program to be
    >perfectly secure all the time without fail.
    >
    I agree whole heartedly. It is interesting to see OpenBSD transition 
    from a stance of "audit is the only way" to actually employing access 
    control and intrusion prevention technologies. It is tough to change 
    your mind on big issues when you have a big public record to live down, 
    so I don't particularly want to abuse Theo for making this policy 
    change. I just want to tease him for choosing ProPolice instead of 
    StackGuard without so much as talking to me :)
    
    >Again, ISTM that the only way to get close to a reasonably secure system
    >is to only rely on the smallest, most audited codebase possible to enforce
    >security policy.  To me this means something enforced by the kernel
    >itself, like standard POSIX permissions and capabilities, NSA Flask,
    >Systrace, SubDomain, LIDS, GRSecurity, etc. (note that this is not a
    >particularly accurate list).  For example one thing that could be done is
    >to automatically build bare-bones systrace profiles at compile time so
    >that any attempt to use a syscall not specified in the source causes the
    >program to immediately abort.  Not a catch-all, but something that raises
    >the bar.
    >
    David Wagner and Drew Dean had a very nice paper at Oakland 2001 on 
    that. Their static analyzer constructed an automata of valid states the 
    program could be in, and a run-time monitor watched the program execute. 
    If the program ever did a state transition that the automata didn't 
    like, the automata would kill the program. The effect is to enforce that 
    the program only execute compliant with its source code, effectively 
    blocking all but the most subtle malcode insertion.
    
        Intrusion Detection via Static Analysis
        <http://www.cs.berkeley.edu/%7Edaw/papers/ids-oakland01.ps>
            David Wagner and Drew Dean. 2001 IEEE Symposium on Security and
            Privacy <http://www.ieee-security.org/TC/sp2001.html>. [pdf
            <http://www.cs.berkeley.edu/%7Edaw/papers/ids-oakland01.pdf>,
            slides
            <http://www.cs.berkeley.edu/%7Edaw/papers/ids-oakland01-slides.ps>]  
    
    Crispin
    
    -- 
    Crispin Cowan, Ph.D.           http://immunix.com/~crispin/
    Chief Scientist, Immunix       http://immunix.com
                http://www.immunix.com/shop/
    



    This archive was generated by hypermail 2b30 : Mon Aug 18 2003 - 14:15:56 PDT