yee@AMES.ARC.NASA.GOV (Peter E. Yee) (11/03/88)
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 yee@ames.arc.nasa.gov ames!yee
rick@SEISMO.CSS.GOV (Rick Adams) (11/03/88)
Please install this patch from Berkeley if you are running sendmail.
---rick
From bostic@okeeffe.Berkeley.EDU Thu Nov 3 06:38:39 1988
Received: from okeeffe.Berkeley.EDU by beno.CSS.GOV (5.59/5.17)
id AA03506; Thu, 3 Nov 88 06:38:26 EST
Received: by okeeffe.Berkeley.EDU (5.61/1.29)
id AA22190; Thu, 3 Nov 88 02:58:55 PST
Date: Thu, 3 Nov 88 02:58:55 PST
From: bostic@okeeffe.Berkeley.EDU (Keith Bostic)
Message-Id: <8811031058.AA22190@okeeffe.Berkeley.EDU>
To: rick@beno.CSS.GOV, spaf@purdue.edu
Subject: Virus (READ THIS IMMEDIATELY)
Status: RO
Guys, if you could post this to whatever appropriate newsgroups,
as soon as possible, we'd appreciate it.
Thanks.
--keith
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.jerry@TWG.COM (Jerry Scott) (11/04/88)
Peter, I guess I am not that familiar with the Unix mail systems of the Sun and Vax. Is this sendmail? Does sendmail have the ability of receiving mail for a process? If so, this is the biggest security hole I have heard about in a long time. Jerry
bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) (11/06/88)
> I guess I am not that familiar with the Unix mail systems > of the Sun and Vax. Is this sendmail? Yes. > Does sendmail have the ability > of receiving mail for a process? If so, this is the biggest security > hole I have heard about in a long time. The problem is the implementation, not the concept. Receiving mail for a process is extremely useful. Three examples, first, a daemon program that automatically files bug reports. Two, a program that replies that you've gotten the mail, but aren't reading it because you're on vacation. Three, a program that takes mail and gateways it to network news groups. --keith
guy@auspex.UUCP (Guy Harris) (11/08/88)
>> Does sendmail have the ability >> of receiving mail for a process? If so, this is the biggest security >> hole I have heard about in a long time. > >The problem is the implementation, not the concept. Receiving mail >for a process is extremely useful. Three examples, first, a daemon >program that automatically files bug reports. Two, a program that >replies that you've gotten the mail, but aren't reading it because >you're on vacation. Three, a program that takes mail and gateways >it to network news groups. Or, putting it another way, the hole exploited by the worm was not the mere ability of "sendmail" to deliver mail to a process; it was the fact that a remote host could force "sendmail" to deliver incoming mail to a process running a command *specified by the remote host*. There may well be some security hole caused by the ability of the *receiving* host to specify that mail to "4bsd-bugs" be sent to the "bugfiler" program, but that's a different matter.
dtynan@sultra.UUCP (Der Tynan) (11/08/88)
In article <8811052345.AA18501@okeeffe.Berkeley.EDU>, bostic@OKEEFFE.BERKELEY.EDU (Keith Bostic) writes: > > > Does sendmail have the ability > > of receiving mail for a process? If so, this is the biggest security > > hole I have heard about in a long time. > > The problem is the implementation, not the concept. Receiving mail > for a process is extremely useful. Three examples, first, a daemon > program that automatically files bug reports. Two, a program that > replies that you've gotten the mail, but aren't reading it because > you're on vacation. Three, a program that takes mail and gateways > it to network news groups. > > --keith I agree with the first poster. It is a BIG security hole. I can understand the justification for piping incoming mail to a process, but this should be done via the 'aliases' file, not the To: line. If I can send mail To: "|program" Then why have a /bin/login at all? This gives me ultimate access to the machine, without ever needing an account. If all I can do, is send mail to an alias, which is in turn, a process, then the final control is from the person who owns the '/usr/lib/aliases' file. Perhaps I'm missing something, but it seems to me, that this is the way the worm propagated. - Der -- dtynan@Tynan.COM (Dermot Tynan @ Tynan Computers) {apple,mips,pyramid,uunet}!zorba.Tynan.COM!dtynan --- God invented alcohol to keep the Irish from taking over the planet ---
guy@auspex.UUCP (Guy Harris) (11/10/88)
>I agree with the first poster. It is a BIG security hole. I can understand >the justification for piping incoming mail to a process, but this should be >done via the 'aliases' file, not the To: line. I suspect the second poster agrees with you; the example he gave is probably implemented via the "aliases" file. The notion of delivering mail to a program is not flawed; the problem is that this should only be at the discretion of the recipient, not the sender.
vixie@decwrl.dec.com (Paul Vixie) (11/10/88)
# I agree with the first poster. It is a BIG security hole. I can understand # the justification for piping incoming mail to a process, but this should be # done via the 'aliases' file, not the To: line. [...] And so it is. Try your example (To: "|foo") and you'll see. The "|programname" syntax is only supposed to work from /usr/lib/aliases and from ~/.forward. It will definitely not work in a header address -- it just doesn't go through the right part of the code at that point. And it would ordinarily not work in a RCPT TO command except that it was allowed to when debug mode was enabled. Berkeley's fix to sendmail turns off the DEBUG command; the proper thing to do is to stop allowing RCPT TO:<|sed -e ...> just because debug mode happens to be enabled. (Which is what I did to the version I run here.) -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013