[1402] in linux-security and linux-alert archive
[linux-security] Re: program xxx is not vulnerable.
daemon@ATHENA.MIT.EDU (Benedikt Stockebrand)
Fri Jan 24 03:53:23 1997
To: linux-security@redhat.com
From: Benedikt Stockebrand <benedikt@devnull.ruhr.de>
Date: 24 Jan 1997 00:15:49 +0100
In-Reply-To: R.E.Wolff@BitWizard.nl's message of Wed, 22 Jan 1997 10:06:19 +0100 (MET)
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
R.E.Wolff@BitWizard.nl (Rogier Wolff) writes:
> As a moderator for linux-security, I cannot take responsibility for
> your security policy. This means that I approve possible bugs even
> when there is no immediate threat.
Aside from your assumed responsibility, I think we all should realize
that security isn't just a matter of plugging the latest bug. With
this attitude we'll move Linux into the same situtation sendmail is
already in --- ``new'' security holes found about monthly and no hope
of a ``secure'' version in the foreseeable future.
I don't blame Eric Allman for this --- he obviously started writing
sendmail when no more than \epsilon people actually cared about
network security and even less knew *how* to do it right --- but we
ought to learn from this. That's the point: If we stick fixing only
security holes that are known to be exploitable or are already
exploited there'll always be folks who are the ones to get bitten
before we move our butts. That sendmail experience (and the BSD
lpr/lpd experience and...and...and...) should tell us to *design*
everything to be safe. Considering the experiences with qmail this
may even work if we start from scratch, but it doesn't really seem
feasible in many other cases. But no matter what we should at least
*try* to do what's reasonable, i.e. fix known holes before the shit
hits the fan. Due to its freely available sources and open developer
community Linux sure has all it really takes to do beat all commercial
Un*ces at least in this respect.
I know only little about the OpenBSD folks (yet...), but apparently
they take a far more ``pro-active'' approach. It seems like they've
been systematically searching their source tree for the usual strcpy()
calls causing buffer overruns and various other standard security hole
patterns. Considering the various CERT advisories and other warnings
in bugtraq and BoS they seem like they've found quite a few
not-yet-exploited security holes that turned ``real'' only a couple
months later. Of course, unless they've already moved a great deal
away from the NetBSD I know (1.1), they'll be dealing with a far
smaller source tree than the average Linux distribution. We probably
can't scan all the RedHat or Debian source trees like this, but at
least we should try both to keep the base system as secure as possible
and deal with potential problems as soon as they are found.
> I suggest we try to tag bug reports between
>
> Everybody should evaluate the consequences.
> and
> only security critical installations need
> to evaluate the consequences.
I wouldn't take the responsibility for classifying found security
holes in this simplified fashion because I consider it highly
over-simplified. There are problems that only relate to
- sites connected to the Internet.
- sites with potentially hostile users.
- hosts providing a very special and uncommon service
(e.g. AppleTalk over IP tunneling).
- hosts with special hardware installed.
- accounts with specific configurations.
- specific distributions.
- ...
We might try something similar to the ``Impact'' section in CERT
Advisories though, stating the conditions under which an attack is
possible. And if we dare we might also add a ``severity/urgency
estimate''. But this should be used mostly with linux-alert, not
linux-security. After all, linux-security is to *discuss* security
aspects of Linux, not to *announce* known problems.
Ben
--
Ben(edikt)? Stockebrand Runaway ping.de Admin---Never Ever Trust Old Friends
My name and email address are not to be added to any list used for advertising
purposes. Any sender of unsolicited advertisement e-mail to this address im-
plicitly agrees to pay a DM 500 fee to the recipient for proofreading services.
