Re: Buffer overflow prevention

From: Mark Tinberg (mtinbergat_private)
Date: Fri Aug 15 2003 - 18:36:42 PDT

  • Next message: Joel Eriksson: "Dropbear SSH Server <= 0.34"

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    
    On Fri, 15 Aug 2003, Peter Busser wrote:
    
    > >   The only way to sleep quietly is still to audit the code at the first place.
    >
    > The only way to sleep quietly in fact is to feed your computer to a shredder.
    >
    > Auditing code alone will not provide much security. In fact, it will lead to a
    > false sense of security. The problem is that a modern UNIX system is that it
    > contains millions of lines of code. Auditing this amount of code is simply
    > impossible. Furthermore, auditors are humans. Humans make mistakes, not only
    > when they are programmers, but also when they are auditors. So audited code
    > will still contain security bugs.
    >
    > In fact, the amount of security in OpenBSD is only slightly less horrible than
    > that of most *NIX operating systems (which includes Adamantix for that matter).
    
    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 don't know how many times I've heard "You should write secure programs,
    the only solution for system security is to write programs that are not
    susceptible to (buffer overflows, heap overflows, format string, etc)
    attacks."  This is an impossibility and a bit of self-abuse to keep
    repeating this mantra.  Repetition won't make it true.
    
    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.
    
    In any event, implementing the above is a far more complicated affair than
    can be accomplished by even an intelligent, knowledgeable and dedicated
    sysadmin.  The only way that there will be significant uptake of more
    comprehensive access control/policy enforcement systems such as the above
    is if they are correctly configured and included by the OS manufacturer.
    OpenBSD seems to be taking the right approach here by developing systrace
    and including systrace profiles for the base system, which is much better
    than the previous approach of trying to perfect the crufty and inadequate
    UNIX "security" model.
    
    I'd like to see the other major OS distributors, Microsoft, RedHat, SuSE,
    Sun, IBM, Novell, etc. take an active part in this and not only provide
    systems with advanced security controls, but also ship them fully
    configured rather than relying on the system administrator who can't
    possibly understand the system well enough to fully configure them.
    
    - -- 
    Mark Tinberg <MTinbergat_private>
    Network Security Engineer, SecurePipe Inc.
    New Key fingerprint = FAEF 15E4 FEB3 08E8 66D5  A1A1 16EE C5E4 E523 6C67
    
    	Your daily fortune . . .
    
    Watson's Law:
    	The reliability of machinery is inversely proportional to the
    	number and significance of any persons watching it.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.0.7 (GNU/Linux)
    Comment: For info see http://quantumlab.net/pine_privacy_guard/
    
    iD8DBQE/PYqrFu7F5OUjbGcRArfFAJsEbws18Ngj78ZfPpwaT+c0PGSjVgCePcES
    agepSknw833x7altZ7VFLYc=
    =tjsu
    -----END PGP SIGNATURE-----
    



    This archive was generated by hypermail 2b30 : Mon Aug 18 2003 - 10:32:37 PDT