postel@VENERA.ISI.EDU (11/05/88)
Hi. I would like to have an RFC written about the Internet "Virus" event to document exactly what actually happened. Virus is in quotes since this was technically a Worm. The RFC should describe features were used, what tricks were used, and how it worked. Also how it was stopped, and what lessons were learned. All the history, the story of its spread and its defeat. This RFC should include all the gory details. This RFC can then be the basis for summary articles in magazines and journals. I think that this RFC should have many authors, as many people contributed to the efforts to understand and stop this program. --jon.
fjd@bridge2.UUCP (Farokh J. Deboo) (11/05/88)
Jon, This is really addressed to the "tcp-ip" community in general: Good idea. A "virus" RFC indeed! My main comment to this state of affairs is the sensationalism associated witht this kind of event. Although it is very fruitful to discuss such issues within closed groups (eg. "tcp-ip"), when at all possible can we please leave the press out of this kind of an event. Publicizing such an event on the 6 o'clock news only tends to encourage the worm- maker, the virus-monger, you name it! Terrorists and hackers really fall into the same category. Let's not glorify them on the front page of the local rag sheet! Farokh Deboo ----------------------- Replied Message Body ----------------------- Date: Fri, 4 Nov 88 12:52:52 PST From: sun!venera.isi.edu!postel Posted-Date: Fri, 4 Nov 88 12:52:52 PST Message-Id: <8811042052.AA00423@bel.isi.edu> Received: by bel.isi.edu (5.54/5.51) id AA00423; Fri, 4 Nov 88 12:52:52 PST To: arpa!tcp-ip@sri-nic Subject: RFC on Internet "Virus", Please Hi. I would like to have an RFC written about the Internet "Virus" event to document exactly what actually happened. Virus is in quotes since this was technically a Worm. The RFC should describe features were used, what tricks were used, and how it worked. Also how it was stopped, and what lessons were learned. All the history, the story of its spread and its defeat. This RFC should include all the gory details. This RFC can then be the basis for summary articles in magazines and journals. I think that this RFC should have many authors, as many people contributed to the efforts to understand and stop this program. --jon.
jon@CS.UCL.AC.UK (Jon Crowcroft) (11/06/88)
Some years ago, we were worried about the security of our mail relay machines, and we set a standard task to all local hackers to try (but with warning) to break the system. Each time a hole was found, we fixed it and also tried to appreciate the general lesson too. general lesson 1 is that you dont allow someone to pull data from a machine over the net without password authentication in any way (e.g. pulling mail, fingerd, rwhod etc are all disabled). general lesson 2 (more obvious) is that you dont let anyone even execute any program on a machine over the net without password authentication, the only exception being the implicit execution of the login program, so there is only one point of entry into execution of arbitary code, and therefore only one point to audit... this still leaves you open to one problem - denial of service if someone sends datas into your system and simply cloggs up the disk - this can be limited to the denial of mail service, and can be kept to a minimum by not talking to machines you havnt heard of (e.g. dont know a name for...) The facilitiy for executing a program on the body oif a message is still allowed in our system, but which program (and on which messages) is specified by recipient only, and not as part of the message - so we could have problems if recipients are careless - but we can monitor that. Having said all this, we are bound to lose, but then we'll learn some more! Maybe there should be an Internet target practice machine jon
scottr@CSC-LONS.ARPA (Scott W. Rogers) (11/07/88)
I to would like to have as much information as possible on the Virus/Worm in order to better protect my site, and the sites my company helps to maintain for the Government. My concern on publishing an RFC is that it might inspire some bored Grad student or disgruntled employee on how to write a better and/or more destructive virus/worm. One suggestion is not to place this RFC in the "public" domain, but to have some intity maintain it and only send it on request. Possible checking out the 's credentials/identity of the requestor first! ------------------------------------------------------------------------ * The opinions expressed here are my own and not those of my employer. * * My employer's secretary may disavow any knowledge of my actions. * ------------------------------------------------------------------------ Scott W. Rogers Computer Sciences Corporation - Systems Division AT&T: (703) 876-1363 3160 Fairview Park Dr. - Falls Church, VA 22152 Fax: (703) 876-4072 Internet: scottr@csc-lons.ARPA ------------------------------------------------------------------------
jherr@umbio.MIAMI.EDU (Jack Herrington) (11/08/88)
in article <8811071522.AA15390@csc-lons.arpa>, scottr@CSC-LONS.ARPA (Scott W. Rogers) says: > > One suggestion is not to place this RFC in the "public" domain, but to > have some intity maintain it and only send it on request. Possible > checking out the 's credentials/identity of the requestor first! > If anything that would only make the hackers more intent on getting it and using it, if we make it avaliable and say that making one would be 'passe' and would be like repeating a bad joke twice, chances are half of the hackers won't care enough to give it the time. -Jack "Got any sweet n' low little fella?" "What--? Elvis?! Elvis Presley?!" "Mum's the work, I tired of the 15-hour workday of the Vegas Headliner..." -Bloom County
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield) (11/09/88)
In article <8811071522.AA15390@csc-lons.arpa> scottr@CSC-LONS.ARPA (Scott W. Rogers) writes: >One suggestion is not to place this RFC in the "public" domain, but to >have some intity maintain it and only send it on request. Possible >checking out the 's credentials/identity of the requestor first! There is always the problem of "checking out the credentials" and who get excluded (when they by rights should be included) and what determined cracker is going to conive his way past the check. This has been under discussion in news.sysadmin concerning the two security mailing lists. The one on zardoz is open to any "system administrator" while the one on isis requires at least one recommendation from the sysadmin on a well recoginized site outside of your organization. Neither is likely to be fool proof (the fools are just to damn ingenious) and I would argue that the crackers have a better grapevine for getting information than browsing through usnet. Admittedly, in some cases security is mandated. The isis list may well be carrying information for which there may be no immediate or practical fix or work-around. It justifiably needs more security than the list on zardoz which should be dealing with more practical preventative recommendations and warnings (hopefully no messages of the "If they do this your dead and there's nothing we can do to stop them!" sort). Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
dwaitzma@bbn.com (David Waitzman) (11/09/88)
People have been talking about needing credentials to get access to certain mailing lists. I agree with those that say that that won't work. I think that Robert Morris, the alleged wormer, has (had) all the right credentials. -david From SNL, 11/5/88: "Remember: When you link up to a computer, you link up to every computer it has ever linked up to."
zjat02@cra2.uucp (Jon A. Tankersley) (11/10/88)
This is interesting. I knew about the isis list, and even got some information on it, but never seemed to get on the list. Guess administring 100+ UNIX systems isn't enough, or maybe not having source..... Not really sure, never got the rejection notice. But I never heard about the zardoz list. Someone needs to publicize some of this a little more. Could boths lists condsider this a request? -tank- #include <disclaimer.h> /* nobody knows the trouble I .... */