bugtraq - Re: Buffer overflow prevention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3F413A59.5090703@immunix.com>
Date: Mon, 18 Aug 2003 13:43:05 -0700
From: Crispin Cowan <crispin@...unix.com>
To: Mark Tinberg <mtinberg@...urepipe.com>
Cc: Peter Busser <peter@...steddebian.org>, bugtraq@...urityfocus.com
Subject: Re: Buffer overflow prevention


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/