Date: Fri, 15 Aug 2003 20:36:42 -0500 (CDT)
From: Mark Tinberg <mtinberg@...urepipe.com>
To: Peter Busser <peter@...steddebian.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Buffer overflow prevention


-----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 <MTinberg@...urepipe.com>
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-----

Powered by blists - more mailing lists