Return-Path: XPUM04@prime-a.central-services.umist.ac.uk Received: from G.SEI.CMU.EDU by ubu.cert.sei.cmu.edu (5.61/2.3) id AA04589; Wed, 20 Jun 90 17:33:24 -0400 Received: from SEI.CMU.EDU by g.sei.cmu.edu (5.61/2.5) id AA07218; Wed, 20 Jun 90 17:33:18 -0400 Received: from nsfnet-relay.ac.uk by sei.cmu.edu (5.61/2.3) id AA23573; Wed, 20 Jun 90 17:32:48 -0400 Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa23484; 20 Jun 90 16:27 BST From: Anthony Appleyard To: DAVIDF@cs.heriot-watt.ac.uk Date: Wed, 20 Jun 90 16:36:28 BST Message-Id: <$TGWGCZNQBTTT at UMPA> Subject: Virus-L vol 0 issue #1103 Virus-L Digest Thu, 3 Nov 88, Volume 0 : Issue #1103 Today's Topics WestWorld "virus" Internet virus comments on EEV vs FEV Re: comments on EEV vs FEV More information on Internet virus described earlier CHECKUP v1.8 diversity of systems (WARNING: MILD FLAME) EEVs on micros INTERNET SENDMAIL VIRUS!!! University of Arizona hit by a virus. Unix virus PRIMOS virus Bitnet bug A worm "condom" A cure!!!!! Computer Network Disrupted by `Virus' Virus on the Arpanet - Milnet More on the virus More on the virus attack More on the virus ------------------------------ Date: Thu, 3 Nov 88 00:37:00 EDT From: X-=*REB*=-X Subject: WestWorld "virus" This evening, I saw the movie WestWorld on HBO or Cinemax. I never thought of it before, but I guess the robots were stuck with a virus. This movie was made in 1972. I guess that that was quite an advanced concept for its time. REB ___________________________________________________________ / From: -=*REB*=- (In Pennsylvania until January...) ", /FoneNet:(0010 0001 0101)1000 0110 0111-1000 0100 0011 0011BCD", /InterNet:kREBaum@Vax1.CC.Lehigh.EDU BitNet: RB00@Lehigh.Bitnet", / SlowNet: 508 E 4th St (positively) Suite #1, Bethlehem, PA 18015", /NJ E-Mail: UUCP: Will this system EVER be up? Only the Shadow knows", /NJ Slownet: 861 Washington Avenue Westwood, NJ 07675 (201)-666-9207 ", !----------------------------------------------------------------------! ! Garcia & Lesh in '88 - Might As Well Party! ! "----------------------------------------------------------------------" -------------------- Date: Thu, 3 Nov 88 09:05:27 EST From: Ken van Wyk Subject: Internet virus The following is a (typed in) reprint of a submission to the TCPIP-L mailing list: Date: Wed, 2 Nov 88 23:28:00 PST From: "Peter E. Yee" Subject: Internet VIRUS alert 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 (ed. Simple Mail Transfer Protocol is the mail protocol used by the TCP/IP based Internet, which includes ARPAnet, MILNET, and a whole slew of others all over the world), 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 (ed. these are the standard background tasks, or daemons, that run on TCP/IP equipped machines; the tasks performed by them include remote login sessions, file transfer sessions, etc.). 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 Ken Kenneth R. van Wyk Calvin: (hammer hammer hammer ...) User Services Senior Consultant Mom: Calvin, what are you DOING to the Lehigh University Computing Center coffee table?! Internet: Calvin: Is this some sort of trick BITNET: question? -------------------- Date: Thu, 3 Nov 88 09:40:18 EST From: "David M. Chess" Subject: comments on EEV vs FEV Ken suggests: > I should think that such a naming convention could be pretty useful > whereby an EEV would be attributable to (presumably) a system programming > error, and an FEV would be attributable to a system design deficiency. I don't know how practical that would really prove. The archetypal virus needs only the following abilities: 1) Find out the names of some executable files on the system 2) Read an executable file 3) Alter an executable file Which of those three abilities deserves to be called a design deficiency? Systems without (1) or (2) are rather crippled from a number of viewpoints, and it's tough to write a complier for a system without (3). I think we have to face the fact that viruses can spread even in a correctly-functioning system without design deficiencies. What we have to do is figure out what to add to such a system to try to minimize the danger of a virus spreading undetected. I guess "doesn't have a good virus-protection system" might count as a design deficiency, but if so, every existing general-purpose system counts as deficient... *8) DC P.S. I'm not really disagreeing with Ken, of course; I'm just using his paragraph as an excuse to toot the usual horn... -------------------- Date: Thu, 3 Nov 88 10:02:04 EST From: Ken van Wyk Subject: Re: comments on EEV vs FEV In-Reply-To: Your message of Thu, 3 Nov 88 09:40:18 EST > I don't know how practical that would really prove. The archetypal > virus needs only the following abilities: > 1) Find out the names of some executable files on the system > 2) Read an executable file > 3) Alter an executable file > Which of those three abilities deserves to be called a design > deficiency? Systems without (1) or (2) are rather crippled from > a number of viewpoints, and it's tough to write a complier for > a system without (3). Well yes, any system needs to be able to do all those things, but they still ought to be limited. The problem isn't that executables need to be altered, but who should be allowed to alter them. Compilers and linkers, of course, should be able to alter executables. Directory listing programs, however, have no business altering executables. Therein lies (what I believe to be) a design deficiency. If a system allows a user to alter any of his/her own files from within any program that he/she can legally execute, isn't that a design deficiency of the operating system itself? There are privileged instructions to do things like terminal i/o - shouldn't file modification be scrutinized more closely as well? In a system where only compilers/linkers can alter executables, and the compilers themselves are in execute-only system filespace maintained by systems personnel, the chances of a FEV (Feature Exploiting virus) spreading would be greatly reduced. > I guess > "doesn't have a good virus-protection system" might count as a > design deficiency, but if so, every existing general-purpose system > counts as deficient... True. Perhaps then, existing operating systems ought to be changed? Ken > P.S. I'm not really disagreeing with Ken, of course; I'm just using > his paragraph as an excuse to toot the usual horn... P.S. I'm not really disagreeing with David, of course; I'm just using his paragraph as an excuse to toot the usual horn... :-) Kenneth R. van Wyk Calvin: (hammer hammer hammer ...) User Services Senior Consultant Mom: Calvin, what are you DOING to the Lehigh University Computing Center coffee table?! Internet: Calvin: Is this some sort of trick BITNET: question? -------------------- Date: Thu, 3 Nov 88 11:48:45 EST From: "Kenneth R. van Wyk" Subject: More information on Internet virus described earlier Just got some more info on that Internet virus. I'm currently checking the newsgroup (see below) for the fix. If/when I find it, I'll post it here. Ken Date: Thu, 3 Nov 88 10:11:37 EST Sender: Network Site Liaisons From: Ross Patterson Subject: Unix virus, beware To: "Kenneth R. Van Wyk" Just a brief note to warn system managers of 4.xBSD systems, particularly Suns and VAXen, that there is a virus in the air. The fix has been posted to NetNews newsgroup "comp.sys.4bsd.ucb-fixes" by Keith Bostick, UC Berkeley. For your system to be affected, it must be running TCP/IP. The virus propagates via mail (using the SENDMAIL daemon) and RSH. We're stomping it out here at Rutgers, using the Bostick's suggestions. Happy hunting. Ross Patterson Rutgers University Center for Computer and Information Services Systems Programming -------------------- Date: Thu, 3 Nov 88 14:16:05 EST From: "David A. Bader" Subject: CHECKUP v1.8 I just received a copy of CHECKUP 1.8 Has anyone else used this version? Any differences from version 1.4?? The author includes a very large and informative text file on anti-viral, anti-trojan horse concerns and applications. -David Bader, DAB3@LEHIGH -------------------- Date: Thu, 3 Nov 88 14:26:00 EST From: Jim Shaffer Subject: diversity of systems (WARNING: MILD FLAME) For the nth time, would everyone out there try to remember that there are computer systems out there besides IBM (both mainframes and PCs)? Although I can usually tell what system someone is talking about by reading the message, there are times when it takes a while. Furthermore, there have got to be people who haven't been around computers long enough to tell what certain terms mean, who will be completely mystified by a reference to a system they've never used. It certainly took *me* long enough to get a clue to what the h--- all the VM/CMS people were talking about, having used only Unix and VMS myself. Jim PS: The references to IBM were only stating the facts. I'm *NOT* trying to start a holy war here! -------------------- Date: Thu, 3 Nov 88 13:01:00 CST From: Kevin Trojanowski Subject: EEVs on micros > I'd also think that EEVs would be more prevalent on micros since there > is no facility for memory protection, etc. Of course, this is an > opinion... To the "garden variety" virus author, technical > specifications for micros are much easier to find than the same for > mainframes; hence writing an EEV to exploit some non-protected > facility (e.g., writing an absolute sector to disk) would be easier > than doing the same on a mainframe. What's more, direct i/o > instructions on most mainframes are privileged instructions and > wouldn't be available to an average user program. More frequently, a > mainframe virus would take advantage of something like file sharing in > order to infect other users' file spaces. If I'm not mistaken (it's been a while since I read the article), but OS/2 provides such protection, on top of providing the basework needed to support virtual memory. Associated with the memory of the 80286 and 80386 running OS/2 is a series of access bits for each process; this preventing the user programs from accessing the kernal, and also preventing them from accessing directly the memory locations needed to deal directly with the hardware. -Kevin Trojanowski troj@umaxc.weeg.uiowa.edu -------------------- Date: Thu, 3 Nov 88 17:11:41 EST From: msmith@TOPAZ.RUTGERS.EDU Subject: INTERNET SENDMAIL VIRUS!!! These are two articles pulled off of news.announce.important on UseNet: - ------------------------------- >From bostic@okeeffe.Berkeley.EDU (Keith Bostic) Thu Nov 3 05:58:55 1988 Path: topaz.rutgers.edu!aramis.rutgers.edu!njin!rutgers!mailrus!purdue!bostic@ok eeffe.Berkeley.EDU From: bostic@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: news@cs.purdue.EDU Followup-To: news.sysadmin Lines: 109 Approved: news@cs.purdue.EDU Xref: topaz.rutgers.edu news.announce.important:21 news.sysadmin:1282 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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. >From news@cs.purdue.EDU (News Knower) Thu Nov 3 14:58:27 1988 Path: topaz.rutgers.edu!aramis.rutgers.edu!rutgers!mailrus!purdue!news From: news@cs.purdue.EDU (News Knower) Newsgroups: news.announce.important,news.sysadmin Subject: Re: The virus Message-ID: <5311@medusa.cs.purdue.edu> Date: 3 Nov 88 19:58:27 GMT Followup-To: news.sysadmin Organization: Department of Computer Science, Purdue University Lines: 24 Approved: news@cs.purdue.EDU Xref: topaz.rutgers.edu news.announce.important:22 news.sysadmin:1283 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 appears to be limited to Internet sites, but may also hit bitnet, I suppose. Mark - -- Mark Smith (alias Smitty) "Be careful when looking into the distance, RPO 1604; P.O. Box 5063 that you do not miss what is right under your nose." New Brunswick, NJ 08903-5063 {backbone}!rutgers!topaz.rutgers.edu!msmith msmith@topaz.rutgers.edu Dukakis/Bentsen on Nov. 8th!!! -------------------- Date: Thu, 3 Nov 88 17:14:00 EST From: I hate mailers that wrap lines Subject: University of Arizona hit by a virus. The following message was forwarded to me from the LINKFAIL distribution list. Does anyone have details on the exact problem the University of Arizona is experiencing? - - Begin forwarded message From: BITNET%"KHAAV@ASUACAD" 3-NOV-1988 16:16 To: POSTMASTER Subj: University of Arizona down Received: From VTVM2(MAILER) by VTCS1 with Jnet id 7149 for POSTMASTER@VTCS1; Thu, 3 Nov 88 16:16 EST Received: by VTVM2 (Mailer X1.25) id 7132; Thu, 03 Nov 88 16:22:18 EST Date: Thu, 3 Nov 88 12:11:38 MST Reply-To: Bob Kaneshige Sender: Link failure announcements From: Bob Kaneshige Subject: University of Arizona down To: "Ron Jarrell (Virginia Tech (VPI))" All Bitnet access to the U of Arizona campus has been suspended until this afternoon due to a virus attack. This includes the following nodes: ARIZRVAX, ARIZJVAX, ARIZVM1, & ARIZMIS. - - End forwarded message -Jeff E. Nelson -Virginia Polytechnic Institute and State University -INTERNET: jen@vtcs1.cs.vt.edu -BITNET: jen@vtcs1.bitnet -------------------- Date: Thu, 3 Nov 88 19:32:33 EST From: Bob Babcock Subject: Unix virus My office mate received this from another mailing list; looks like it should be of interest here: >Date: Thu, 3 Nov 88 10:11:37 EST >Reply-To: Network Sites Liaison >Sender: Network Sites Liaison >From: Ross Patterson >Subject: Unix virus, beware >To: "John F. Chandler" > > Just a brief note to warn system managers of 4.xBSD systems, >particularly Suns and VAXen, that there is a virus in the air. The >fix has been posted to NetNews newsgroup "comp.sys.4bsd.ucb-fixes" by >Keith Bostick, UC Berkeley. For your system to be affected, it must >be running TCP/IP. The virus propagates via mail (using the SENDMAIL >daemon) and RSH. We're stomping it out here at Rutgers, using the >Bostick's suggestions. Happy hunting. > >Ross Patterson >Rutgers University >Center for Computer and Information Services >Systems Programming -------------------- Date: Thu, 3 Nov 88 19:59:00 EST From: ACS045@GMUVAX Subject: PRIMOS virus Does anybody out there know of any virii either old or new that would infect a ring-network of PR1ME computers running PRIMOS?---any confirmations/denials /info would be greatly appreciated(One question I seem to have forgotten to ask at the Conference when I had the chance) - -Steve -------------------- Date: Thu, 3 Nov 88 21:31:46 CST From: James Ford Subject: Bitnet bug Text taken from LINKFAIL. Also, the TCPIP bug that apparently is going around made CNN news. CNN stated that the FBI is going to investigate the matter. My question is can the FBI trace something like this? The XMAS bug was traced via old NETLOG files and among other things............. JF - -------------------------------------------------------------------- >Date: Thu, 3 Nov 88 12:11:38 MST >Sender: Link failure announcements >All Bitnet access to the U of Arizona campus has been suspended until >this afternoon due to a virus attack. This includes the following nodes: >ARIZRVAX, ARIZJVAX, ARIZVM1, & ARIZMIS. ------------------------------ Date: Thu, 03 Nov 88 21:20:10 EST From: Gene Spafford Subject: A worm "condom" Organization: SERC, Department of Computer Sciences, Purdue Univ. Comment: Copied from RISKS-FORUM Digest ... Kevin Braunsdorf & Rich Kulawiec (Purdue-CC) have come up with a "condom" to protect your machine against the CURRENT worm. They are not 100% sure it works, but it seems to be completely effective and it can't do any harm. As ROOT, do: mkdir /usr/tmp/sh chmod 111 /usr/tmp/sh Then edit your rc.local file to recreate the directory in case of a reboot. This will not stop a current infection, but it will prevent any new ones from taking hold -- it prevents the worm from creating replicas. ... --spaf -------------------- Date: Thu, 03 Nov 88 22:04:15 EST From: Gene Spafford Subject: A cure!!!!! Organization: SERC, Department of Computer Sciences, Purdue Univ. Comment: Copied from RISKS-FORUM Digest FLASH!! Kevin ("Adb's your friend.") Braunsdorf 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 exiting. 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 will prevent reinfection. # 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-*-*' Xextern int pleasequit = -1; *-*-END-of-foo.c-*-* exit -------------------- Date: Thu, 3 Nov 88 21:30:19 PST From: geoff@fernwood.mpk.ca.us (the tty of Geoff Goodfellow) Subject: Computer Network Disrupted by `Virus' Comment: Copied from RISKS-FORUM Digest COMPUTER NETWORK DISRUPTED BY `VIRUS' By JOHN MARKOFF= c.1988 N.Y. Times News Service= In an intrusion that raises new questions about the vulnerability of the nation's computers, a nationwide Department of Defense data network has been disrupted since Wednesday night by a rapidly spreading ``virus'' software program apparently introduced by a computer science student's malicious experiment. The program reproduced itself through the computer network, making hundreds of copies in each machine it reached, effectively clogging systems linking thousands of military, corporate and university computers around the country and preventing them from doing additional work. The virus is thought not to have destroyed any files. By late Thursday afternoon computer security experts were calling the virus the largest assault ever on the nation's computers. "The big issue is that a relatively benign software program can virtually bring our computing community to its knees and keep it there for some time," said Chuck Cole, deputy computer security manager at Lawerence Livermore Laboratory in Livermore, Calif., one of the sites affected by the intrusion. "The cost is going to be staggering." Clifford Stoll, a computer security expert at Harvard University, added: "There is not one system manager who is not tearing his hair out. It's causing enormous headaches." The affected computers carry routine communications among military officials, researchers and corporations. While some sensitive military data are involved, the nation's most sensitive secret information, such as that on the control of nuclear weapons, is thought not to have been touched by the virus. Computer viruses are so named because they parallel in the computer world the behavior of biological viruses. A virus is a program, or a set of instructions to a computer, that is deliberately planted on a floppy disk meant to be used with the computer or introduced when the computer is communicating over telephone lines or data networks with other computers. The programs can copy themselves into the computer's master software, or operating system, usually without calling any attention to themselves. From there, the program can be passed to additional computers. Depending upon the intent of the software's creator, the program might cause a provocative but otherwise harmless message to appear on the computer's screen. Or it could systematically destroy data in the computer's memory. The virus program was apparently the result of an experiment by a computer science graduate student trying to sneak what he thought was a harmless virus into the Arpanet computer network, which is used by universities, military contractors and the Pentagon, where the software program would remain undetected. A man who said he was an associate of the student said in a telephone call to The New York Times that the experiment went awry because of a small programming mistake that caused the virus to multiply around the military network hundreds of times faster than had been planned. The caller, who refused to identify himself or the programmer, said the student realized his error shortly after letting the program loose and that he was now terrified of the consequences. A spokesman at the Pentagon's Defense Communications Agency, which has set up an emergency center to deal with the problem, said the caller's story was a "plausible explanation of the events." As the virus spread Wednesday night, computer experts began a huge struggle to eradicate the invader. A spokesman for the Defense Communications Agency in Washington acknowledged the attack, saying, "A virus has been identified in several host computers attached to the Arpanet and the unclassified portion of the defense data network known as the Milnet." He said that corrections to the security flaws exploited by the virus are now being developed. The Arpanet data communications network was established in 1969 and is designed to permit computer researchers to share electronic messages, programs and data such as project information, budget projections and research results. In 1983 the network was split and the second network, called Milnet, was reserved for higher-security military communications. But Milnet is thought not to handle the most classified military information, including data related to the control of nuclear weapons. The Arpanet and Milnet networks are connected to hundreds of civilian networks that link computers around the globe. There were reports of the virus at hundreds of locations on both coasts, including, on the East Coast, computers at the Massachusetts Institute of Technology, Harvard University, the Naval Research Laboratory in Maryland and the University of Maryland and, on the West Coast, NASA's Ames Research Center in Mountain View, Calif.; Lawrence Livermore Laboratories; Stanford University; SRI International in Menlo Park, Calif.; the University of California's Berkeley and San Diego campuses and the Naval Ocean Systems Command in San Diego. A spokesman at the Naval Ocean Systems Command said that its computer systems had been attacked Wednesday evening and that the virus had disabled many of the systems by overloading them. He said that computer programs at the facility were still working on the problem more than 19 hours after the original incident. The unidentified caller said the Arpanet virus was intended simply to "live" secretly in the Arpanet network by slowly copying itself from computer to computer. However, because the designer did not completely understand how the network worked, it quickly copied itself thousands of times from machine to machine. Computer experts who disassembled the program said that it was written with remarkable skill and that it exploited three security flaws in the Arpanet network. [No. Actually UNIX] The virus' design included a program designed to steal passwords, then masquerade as a legitimate user to copy itself to a remote machine. Computer security experts said that the episode illustrated the vulnerability of computer systems and that incidents like this could be expected to happen repeatedly if awareness about computer security risks was not heightened. "We needed something like this to bring us to our senses. We have not been paying much attention to protecting ourselves." Peter Neumann, a computer security expert at SRI International Inc. in Menlo Park International, said: "Thus far the disasters we have known have been relatively minor. The potential for rather extraordinary destruction is rather substantial. In most of the cases we know of, the damage has been immediately evident. But if you contemplate the effects of hidden programs, you could have attacks going on and you might never know it." [* Following is Geoff's full quote ("exploitation"), which John only partially integrated with Geoff's earlier off-the-cuff comment ("accident"): "This was an exploitation wanting to happen. We deserved it. We needed something like this to bring us to our senses. We have not been paying much attention to protecting ourselves. The blame does not rest on the R&D community as a whole. Look how many manufacturers [...] just took the original computer-science-department developed code willy-nilly, put their wrapper and corporate logo on it, and resold it to customers. That's the real travesty here, we build these systems, OK, that's great, but we rarely build them and then ask how they might be abused, broken, or circumvented" {and then try to break them}. ] -------------------- Date: Thu, 3 Nov 88 06:46 EST From: Stoll@DOCKMASTER.ARPA Subject: Virus on the Arpanet - Milnet Comment: Copied from RISKS-FORUM Digest Re Arpanet "Sendmail" Virus attack November 3, 1988 Hi Gang! It's now 3:45 AM on Wednesday 3 November 1988. I'm tired, so don't believe everything that follows... Apparently, there is a massive attack on Unix systems going on right now. I have spoken to systems managers at several computers, on both the east & west coast, and I suspect this may be a system wide problem. [Symptom]: hundreds or thousands of jobs start running on a Unix system bringing response to zero. [Systems attacked]: Unix systems, 4.3BSD unix & variants (eg: SUNs) any sendmail compiled with debug has this problem. See below. This virus is spreading very quickly over the Milnet. Within the past 4 hours, I have evidence that it has hit >10 sites across the country, both Arpanet and Milnet sites. I suspect that well over 50 sites have been hit. Most of these are "major" sites and gateways. [Method]: Apparently, someone has written a program that uses a hole in SMTP Sendmail utility. This utility can send a message into another program. Step 1: from a distant Milnet host, a message is sent to Sendmail to fire up SED, (SED is an editor) This is possible in certain versions of sendmail (see below). 2: A 99 line C program is sent to SED through Sendmail. 3: The distant computer sends a command to compile this C program. 4: Several object files are copied into the Unix computer. There are 3 files: one targeted to Sun one targeted to SUN-3 one targeted to vax (ultrix probably, not vms) 5: The C program accepts as address other Milnet sites 6: Apparently, program scans for other Milnet/arpanet addresses and repeats this process. [The bug in Sendmail]: When the Unix 4.3 BSD version of Sendmail is compiled with the Debug option, there's a hole in it. Most Unix systems (BSD 4.3 and Suns) apparently do not have this bug. It exists only where the system manager recompiled Sendmail and enabled debugging. This is bad news. Cliff Stoll dockmaster.arpa -------------------- Date: Thu, 03 Nov 88 09:52:18 EST From: Gene Spafford Subject: More on the virus Organization: SERC, Department of Computer Sciences, Purdue Univ. Comment: Copied from RISKS-FORUM Digest All of our Vaxen and some of our Suns here were infected with the virus. The virus 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 virus seems to consist of two parts. I managed to grab the source code for one part, but not the main component (the virus cleans up after itself so as not to leave evidence). 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 gets a shell. 2) The shell creates a file in /tmp named $$,l1.c (where the $$ gets replaced by the current process id) and copies code for a "listener" or "helper" program. This is just a few dozen lines long and fairly generic code. The shell compiles this helper using the "cc" command local to the system. 3) The helper is invoked with arguments pointing back at the infecting virus (giving hostid/socket/passwords as arguments). 4) 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 virus 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: 5) The newly exec'd shell attempts to compile itself from the files copied over to the target machine. I'm not sure what else the virus does, if anything -- it may also be attempting to add a bogus passwd file entry or do something to the file system. The helper program has an array of 20 filenames for the "helper" to copy over, so there is room to spare. There are two versions copied -- a version for Vax BSD and a version for SunOS; the appropriate one is compiled. 6) The new virus is dispatched. This virus opens all the virus 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 virus 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). The heavy load we see is the result of multiple viruses coming in from multiple sites. Since local hosts files tend to have entries for other local hosts, the virus tends to infect local machines multiple times -- in some senses this is lucky since it helps prevent the spread of the virus as the local machines slow down. The virus also "cleans" up after itself. If you reboot an infected machine (or it crashes), the /tmp directory is normally cleaned up on reboot. The other incriminating files were already deleted by the virus itself. Clever, nasty, and definitely anti-social. --spaf -------------------- Date: Thu, 3 Nov 1988 14:27:22 PDT From: Peter Neumann Subject: More on the virus attack Comment: Copied from RISKS-FORUM Digest Remember that the above are preliminary messages relating to an event in progress. There seem to be many unanswered questions. Perhaps someone will contribute a definitive report to the next issue of RISKS. Examination of the code suggests a fairly sophisticated person writing relatively high quality (although undocumented) code, exploiting several flaws that exist(ed) on many UNIX systems, and written with considerable good practice in self-checking, reliability, etc. From the evidence thus far, I would guess it that this was a deliberate attack, not an accidental experiment run astray. Although it was primarily a denial of service attack, it did some remarkable things, taking advantage of many different approaches. The spawned processes appear to have been doing attacks on encrypted passwords to enable ftps (in case the .rhost attack would not work -- cf. the Stanford breakins described in CACM and SEN by Brian Reid). Separate versions to run on Suns and Vaxens were apparently propagated in DES encrypted form, decrypted, and both programs tried to see which one would work. We quoted Henry Petroski here over a year ago to the effect that we do not learn from our successes, but that we have an opportunity to learn from our failures. Once again we are presented with the opportunity to learn that many of our computer systems have serious security vulnerabilities, and that we need to take pains to defend against the really malicious attacks. Strangely some people take heart in the fact that the security attacks to date (whether penetrations, exploitations of privilege, Trojan horses, or legitimate viruses) have been relatively modest in scale, perhaps to justify the absence of concern. I am afraid that it will take a Chernobyl- or Three-Mile-Island-like disaster before the community at large wakes up. PGN -------------------- Date: Thu, 3 Nov 88 16:32:25 EST From: bishop@bear.Dartmouth.EDU (Matt Bishop) Subject: More on the virus Comment: Copied from RISKS-FORUM Digest ... This program introduced itself through a bug in sendmail. At these sites, sendmail was compiled and installed with a debugging option turned on. As near as I can figure (I don't have access to the sendmail sources), by giving a specific option to the "debug" command in sendmail (there are lots of those, controlling what exactly you get information about) you can cause it to execute a command. As sendmail runs setuid to root, guess what privileges the command is executed with. Right. Apparently what the attacker did was this: he or she connected to sendmail (ie, telnet victim.machine 25), issued the appropriate debug command, and had a small C program compiled. (We have it. Big deal.) This program took as an argument a host number, and copied two programs -- one ending in q.vax.o and the other ending in .sun.o -- and tried to load and execute them. In those cases where the load and execution succeeded, the worm did two things (at least): spawn a lot of shells that did nothing but clog the process table and burn CPU cycles; look in two places -- the password file and the internet services file -- for other sites it could connect to (this is hearsay, but I don't doubt it for a minute.) It used both individual .rhost files (which it found using the password file), and any other remote hosts it could locate which it had a chance of connecting to. It may have done more; one of our machines had a changed superuser password, but because of other factors we're not sure this worm did it. This last part is still sketchy; I have the relevant sun.o file and will take it apart to see just what it was supposed to do. As of now, it appears there was no serious damage (just wasted CPU cycles and system administrator time). Two obvious points: 1. Whoever did this picked only on suns and vaxen. One site with a lot of IRISes and two Crays (ie, NASA Ames) got bit on their Suns and Vaxen, but the attempt to get the other machines didn't work. 2. This shows the sorry state of software and security in the UNIX world. People should NEVER put a program with debugging hooks in it, especially when the hook is (or can be made) to execute an arbitrary command. But that is how the sendmail which was used was distributed! One more interesting point: initially, I thought an application of the "principle of least privilege" would have prevented this penetration. But the attacker used a world-writeable directory to squirrel the relevant programs in, so -- in effect -- everything could have been done by any user on the system! (Except the superuser password change, of course -- if this worm did in fact do it.) I think the only way to prevent such an attack would have been to turn off the deug option on sendmail; then the penetration would fail. It goes to show that if the computer is not secure (and like you, I don't believe there ever will be such a beastie), there is simply no way to prevent a virus (or, in this case, a worm) from getting into that system. I know this is somewhat sketchy, flabby, and fuzzy, but it's all I know so far. I'll keep you posted on developments ... Matt ...................................................................... Greg Lypowy P.S. Chris Haller, what have things been like at Cornell (where this 'virus' is purported to have emanated?? P.P.S. To You All -- Is this a true virus or could we better define it as a worm?? -------------------- *** end of Virus-L issue ***