🚀 go-pugleaf

Well,  Looks like we have (re)uncovered a can of mixed worms here.
The example I gave was definitely in the "security" area and you
should note that the method used to get it fixed involved exactly
one "outside site", the site of the author of the operating system.

The example of the broadcast that went "astray" is more accurately
described as an "integrity" issue.  With integrity one is concerned
that the "system/facility" stay alive and functional under both
normal use and many forms of abnormality.  What we are learning
with some of the facilities for message sending is that our
"internet" is very highly connected and even can be considered
to be too highly connected for some forms of (even innocent)
misbehavior.  How do we benefit from what we have learned thus far?

Dennis has suggested that one of the manufacturers fix some code
and/or defaults and/or procedures in its releases.  I'm sure other
manufacturers can do likewise should they also exhibit the
same misfeatures in their offerings.  But the big thing that we
need to understand is that we do not understand how to live
in these highly connected internets yet.  Much more research needs
to happen in the area of intergroup interactions.  And much more
tolerance needs to be exhibited towards those who are probing
the edges of all this.

Dan
-------

>> Whoa!
>> 
>> Encouraging people to find holes and then use them to make the local system
>> programmers work on them is wrong. It is like encouraging people to find out
>> if their neighbors lock their door during the day so they will. Do you really
>> want that or do you want the theives to be caught? I want the theives to be
>> caught and the ability to leave my door open. I don't want to fear my
>> neighborhood or my users.

While this doesn't deal directly with TCP-IP, it is a *very* important
consideration in the Internet in particular, and any network in general.

Often a so-called 'breakin' does not even require that a user maliciously
"try their neighbors doors" to see if they can gain restricted permissions
or access.  Often curiosity alone is enough to cause problems. Example 1:
a first-time UNIX user was learning about the file system, and in particular
how to delete files.  He was told that he could only delete files owned by
him, and by way of counterexample his mentor typed "rm /etc/passwd".
Surprise, /etc was writeable and the file was gone.  Example two: the recent
rlogin breakins at Stanford.  Example 3: Obviously if you have hardware
access to the transmission medium you can unintentionally wreak havoc merely
by using someone elses IP address.

I too would like to live in a word where I can leave my "door unlocked".
Unfortunately it doesn't take more than a very few nasty or ignorant persons
to cause problems.  Due to the fact that computers have evolved in an
atmosphere of sharing (time sharing, memory sharing, src sharing..)
we have yet to realize the responsibilities and risks of trusting them too
much.  I.e., there is a big difference between leaving your door
unlocked but closed, and spreading $20.00 bills on your front lawn.
In the case of J. Hubbards 'wall' to the Net, the problem was not
caused by a malicious person, but by simple curiosity.

At the recent TCP/IP Conference in Monterey CA, some discussion was
given to "network security".  From the military standpoint they want
the ability to send data through a network, such that anyone who
captures the data won't be able to read or use it.  While this may
be a prerequisite for the military, I don't think that 'normal' users
should expect that their Email be any more secure than their USMail.
The best method of keeping something secure on a network is to physically
seperate it.  Or, do what I do, and don't put anything on the system
which you wouldn't read by someone else under the worst case scenario.

Fixing security 'features' is obviously important, and should be pursued.
Catching malicious persons doing damage is also extremely important.  But
"catching the theives" is not the answer to a lack of network security.
If your network rolls out a red-carpet to someone then don't be surprised
if you find muddy footprints on it the next morning.  I leave you with
two examples quoted from the January 1987 issue of the ACM Software
Engineering Notes...

	"The computer security administrator at Roche ... had been
	 plagued by a hacker who auto-dialed the entire Roche phone
	 system in sequence.  .... They laid a hacker trap on one of
	 the PC's and traced the call.  Once the suspect was found,
	 it was even harder to get him arrested since he was in
	 New York, and Roched in New Jersey (which got the FBI involved).
	 The perp was brought into the police station and had the riot
	 act read to him...  He was not charged -- because there wasn't
	 a **no-trespassing** sign on the hacker trap identifying the
	 system as private proberty of Roche."

	 " "Welcome to the ______ System" ... A Mass. financial firm
	  that had attempted to prosecute a hacker who had penetrated
	  their system.  The defense lawyer argued that the system had
	  a greeting that welcomed people to the system, and that was 
	  tantamount to welcoming someone intor your home.  The judge
	  threw out the case, accepting the arguments of the defense.."

Robert Allen,
robert@spam.istc.sri.com