Path: utzoo!utgpu!attcan!lsuc!sickkids!mark
From: mark@sickkids.UUCP (Mark Bartelt)
Newsgroups: news.sysadmin
Subject: Re: Possible Fines for Virus Perpetrator
Message-ID: <111@sickkids.UUCP>
Date: 10 Nov 88 13:51:16 GMT
References: <456@l5comp.UUCP> <12081@dscatl.UUCP> <16600@agate.BERKELEY.EDU> <5331@medusa.cs.purdue.edu>
Reply-To: mark@sickkids.UUCP (Mark Bartelt)
Distribution: na
Organization: Hospital for Sick Children, Toronto
Lines: 53

In article <5331@medusa.cs.purdue.edu> spaf@cs.purdue.edu (Gene Spafford)
comments, somewhat disingenuously, ...

>                                                             I suspect
> that Sun Microsystems will expend a few $100K on this -- not only to
> eradicate the worm in their internal network, but they will have the
> expense of FedEx'ing copies of patches to all their sites under
> maintenance.  DEC will have similar costs.  Then there is BBN and....

Perhaps true, but totally irrelevant to the question of whether the person
responsible for the virus/worm/whatever (actually, based on its behaviour,
I prefer to call it a caterpillar) is a bad boy or a hero.  Not true in any
event in the case of DEC, from what I've heard.  If Sun has to spend big
bucks to get fixes out to their customers, I'm afraid I won't be the least
bit inclined to shed a tear, since they'll be paying the price now for past
laziness.  As Geoff Goodfellow observed (quoted from comp.risks):

>                        Look how many manufacturers [...] just took the
> original computer-science-department developed code willy-nilly, put their
> wrapper and corporate logo on it, and resold it to customers.  That's the
> real travesty here, we build these systems, OK, that's great, but we rarely
> build them and then ask how they might be abused, broken, or circumvented.

Excellent point.  And it seems that if a large, successful company takes
the easy way out, namely grabbing a gigantic collection of software, much
of it written by graduate students (even undergraduates?) of widely varying
talent, and calling it a "product" without spending the time and effort to
apply the same quality control standards to it that they would normally use
for products written in-house, they're simply asking for trouble.  To their
credit (and, presumably, with gratitude from their customers), Digital seems
to have done the Right Thing with Ultrix.  Whether this was by design or by
accident, I have no way of knowing.

Of course, one can argue that sendmail is so huge, complex, and difficult
to understand that it's impossible to assess its quality (or lack of same).
This is certainly true.  For that reason, our site is, always has been, and
always will be a sendmail-free zone (my thanks to Geoff Collyer for coining
a good term to go along with a sensible concept).  One of the first things
I did when we brought up our system was to remove sendmail (and a number of
other setuid things as well).  It's just common sense to minimize the number
of things that run setuid (especially setuid root).  I don't bother worrying
about programs that I can get a mental handle on.  For example, su.c is all
of 187 lines long, so I can be certain that it does what it's supposed to do.
But sendmail is *seventeen thousand* lines of code!  As you old-timers will
recall, that's nearly twice the size of the Sixth Edition kernel!  We have
seen other security-related sendmail bugs in the past, and I wouldn't be at
all surprised if there will be more in the future.  How can anybody really
know for certain?  It's an atrocity and a monstrosity (hey, do I sound like
Jesse Jackson yet?), and should be avoided at all costs.  End of editorial.

Mark Bartelt                          UUCP: {utzoo,decvax}!sickkids!mark
Hospital for Sick Children, Toronto   BITNET: mark@sickkids.utoronto
416/598-6442                          INTERNET: mark@sickkids.toronto.edu