Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!chinet!ignatz
From: ignatz@chinet.UUCP
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: Irresponsibility (Was: Security problem on UNIX PC's)
Message-ID: <1646@chinet.UUCP>
Date: Tue, 29-Sep-87 10:39:00 EDT
Article-I.D.: chinet.1646
Posted: Tue Sep 29 10:39:00 1987
Date-Received: Fri, 2-Oct-87 00:49:10 EDT
References: <54@quincy.UUCP> <149@manta.UUCP>
Reply-To: ignatz@chinet.UUCP (Dave Ihnat)
Organization: Analysts International Corporation
Lines: 55
Keywords: security, root, problem, unix-pc
Xref: utgpu junk:5918 comp.sys.att:1169
Summary: Not wrong in this case.

Brent Cheikes criticized Lenny Tropiano's posting of security holes on
the Unix/PC (3B1, etc.) in the referenced article; as both another
individual and Lenny have defended the posting item-by-item, I won't
go into that here.  But I would like to point out that, in general
usage, Lenny's posting is quite proper.

If you find that some people always leave the keys in their unlocked
cars, you buy public service time and have one of those "Take a
*chomp* bite out of crime!" commercials.  If you discover that any
person can calculate the last digits of the telephone company credit
card by a simple algorithm, you don't responsibly publish the fact
until the algorithm has been changed and new cards issued.  In the
latter case, "phone phreaks" may publish the algorithm, but
responsible individuals neither do so nor perpetuate the handout.

Sound familiar?  Both are "real world" security situations that have
really occurred.  In both cases, the operative definition of proper
behavior was whether the knowledge of the security hole also included
the information necessary to close it, and the person at risk had the
means to easily do so.  Start locking your car, and take the keys.
Ok, simple enough.  But you couldn't re-issue your telephone card
number; at best, you could cancel it.  As another example, fixable
security holes have been publicized in such publications as Unix
Review.

So it is in this case.  In all of the security issues Lenny mentioned,
there was also a simple fix provided that anyone--with or without a
development system--could apply.  And there are security holes that
are known among those of us who worry about such things, but can't be
reasonably fixed without kernel or utility source.  *These* do not
make it on the net; if they do, they fall under the purview of criticism
such as Brent's. 

I might point out that a common practice in the past was, if you *did*
find a security hole that wasn't fixable, the fact that you knew of
such a problem might be posted, along with offers to legitimate SA's
to snail-mail the problem (and any workarounds, or at least detection
methods), if they could prove their legitimacy.  When most Unix
systems were owned/operated by companies, this was relatively
easy--mail a copy of your site license agreement, and/or a note on
company letterhead.  It's a bit more difficult now, but can still
work.

Common sense--or, if you will, proper application of "fuzzy
logic"--should prevail in deciding what to post, and what to hint
at...

			Dave Ihnat
			Analysts International Corporation
			ihnp4!homebru!ignatz || aicchi!ignatz || chinet!ignatz
			(w) (312) 882-4673  (h) (312) 784-4544
-- 
			Dave Ihnat
			ihnp4!homebru!ignatz || ihnp4!chinet!ignatz
			(w) (312) 882-4673