[news.sysadmin] virus...

bostic@okeeffe.Berkeley.EDU (Keith Bostic) (11/03/88)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.

debra@alice.UUCP (Paul De Bra) (11/08/88)

From what I learned about the virus (or worm) so far, the big security hole
was known for quite a long time and yet Berkeley and Sun were still shipping
their OS with the hole.

That's like selling houses with no lock on the back door, knowing that this
is a problem, but not doing anything about it. I am not saying that everyone
should have maximum security on his house, but there are certain minimal
requirements (for insurance for instance).

Sometimes it takes a disaster to make people realize that there is a problem.
Although it is still not justified to walk into someone's home, I'd rather
have the intruder just leave a note behind saying "Gee, do you know you have
no lock and anyone can get in with no effort and without breaking anything
and steal whatever they want?" than to find an empty house one day.

The real problem in Morris' case is to decide whether what he did is 
comparable to leaving a note behind, or whether there are more malignant
aspects to his worm.

Luckily most administrators took this warning seriously and improved their
security before a real malignant person walked through the open back door
to copy vital information or delete everything. Remember that with Challenger
there also had been warnings from experts, but it took a disaster to initiate
a necessary increase in safety measurements.

Fixing the security problem exposed by the worm of course cost a lot of money.
But you can't hold Morris' responsible for that I think, because this fix had
to be implemented anyway, and it should have been implemented a long time ago.
Of course the fix would have been cheaper if it had been implemented in time...

Paul.
-- 
------------------------------------------------------
|debra@research.att.com   | uunet!research!debra     |
------------------------------------------------------