Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!ucbvax!NSIPO.NASA.GOV!medin
From: medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Morris bashers...
Message-ID: <8811141805.AA14106@nsipo.arc.nasa.gov>
Date: 14 Nov 88 18:05:29 GMT
References: <3481@hubcap.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 110


Well, let me throw in my opinion here.  With regards to the bugs
used by the virus, I, nor any of my friends at UCB knew about
them.  I don't believe anyone in the CSRG at UCB knew about them.
If we had, one of us would have seen to it that it would have been
fixed.  Just look at the number of security related patches that
UCB has put out on comp.bugs.ucb-fixes in the past year.  People
are serious about fixing bugs in 4.3, but UCB, and I doubt 
anyone else are out there, are auditing code.  

The CSRG releases a RESEARCH operating system called Berkeley
Unix.  It happens to be a very useful release, and many people
use it, but it is not a product.  There is no software
warranty, and it's fairly cheap.  So I don't have problems with
the CSRG about these bugs; they only do best effort work, and
they really don't even need to do that.  Where I do find a LOT
of problems is what the vendor community is doing here.  SUN and
DEC produce 'products' out of Berkeley Unix.  They charge real
money for these products.  Yet Sun for example had a serious
security bug in one of the network utilities that they knew
about for a year (I have the bug report number), and didn't 
issue a patch at all, but waited for 4.0 to fix the problem.
This is ridiculous.  DEC is just as bad.  It's the vendors
who have the responsibility for auditing the code they release.
Go scream at SUN for not finding the bug, not at Berkeley.

Further, you will always get less buggy code from the CSRG
than the vendor community.  Why is that?  The vendor
community normally tracks 4.3 pretty well, though lags
by an inordinate period of time often enough.  If SUN or DEC
finds a bug, they usually tell CSRG about it and
fix it.  CSRG then fixes it internally, and if appropriate,
shortly afterwards releases a bug fix over the network.  They
also get bug reports from others as well.  So CSRG typically
fixes bugs quickly.  SUN and DEC and company don't usually
issue patches; they wait for the next rev. of OS release.  
Further, often times the development people fix the bug in the 
code they are using, not in what the 'software manufacturing' 
group is distributing.  So they need to retrofit the fix.
What it boils down to is that 4.3 has the fixes out soon
after they know about it.  The vendors wait huge periods
of time unless some sort of crisis develops.  You see the
recent postings about ftpd bug fixes to comp.bugs.ucb-fixes?
Have SUN or DEC released patches yet?  Do you really think
that bug is only in 4.3?  The first thing I do when bringing
up a SUN release (I'd do the same thing if I had Vaxstations 
instead of SUNs) is throw away all the vendor distributed network
code and port the latest 4.3 utilities.  They work better 
in general and have fewer bugs (read security problems).
Also, this way I have source code, so when UCB issues a
bug fix, I can fix it in 5 minutes, as opposed to feverishly
beating on my vendor to give me a binary patch that 
probably hasn't even been produced in the company yet.
Folks, for security reasons alone, insist on source code!

Mike Padilipsky has a chapter in his book "Elements of Networking
Style" called "The Myth of Vendor Support".  It's good reading.
Anyone from SUN or DEC want to throw rocks at what I've said?
I'd love to be proven wrong!

Now, about Morris.  Firstly, we don't know if he's responsible
for this thing.  Unless someone has seen a confession, we really
don't know if he's the one yet.  He may well be, but it's
not absolutely clear yet.  But if he is the guy, then the FBI
MUST be able to sucessfully argue a felony case against him
and lock him up.  It makes no difference what his intentions
were or are.  If he did it, he needs to be made an example of.
People playing around occaisionally and attempting to crack
a system out of a sense of novelty is one thing, but something
as large and as well publicized as this virus requires action.
The Internet operates fairly freely, but always has this notion
of a heavy weight somewhere above that can drop on troublemakers
and squash them out of existance.  Otherwise what happens is
that you get a bunch of urchins attacking things all over
the place, and then you have to start restricting the
openess of the network, and thereby lessening it's utility.
So, when people cause this much trouble, they need to be 
vigorously prosecuted.  Fortunately, I believe the laws here
don't require proof of malice, only proof of damage.  And
I'm sure that the various government agencies involved 
spent a pile of money (in terms of people's time) to squash
this thing, so that shouldn't be hard to prove.

Some people are saying that since the virus wasn't intentionally
harmful, that all this fuss is really no big deal, and it should
be fixed, but is not that big of a deal.  As a person who
was fighting it fairly early on, I'd have to say that we didn't
know it wasn't harmful until we saw the decompiled code a few
days later.  When we were trying to purge our systems of
the thing, we had to assume worst case and that the thing
was harmful.  We had no reason to assume it wasn't.  So we
put in a lot of work to squash it.  It was the prudent thing
to do.

And lastly, let's not forget this was a computer problem, not
a network problem.  Sure the network facilited it's travel,
but not all computers on the net were affected.  As my boss
at NASA HQ said, you don't shut down the Interstate highway 
system just because some burgler traveled a freeway on the
way to robbing someone's house.  You beef up security at
the house, not close all the off-ramps.  If you are concerned
about security, make sure your systems are well administered
and managed.  That's the best thing you can do to avoid problems.

					Thanks,
					   Milo

PS All the usual disclaimers about this not being the opinion
of the US Government, Sterling Software, etc... apply here
of course...