VIRUS-L Digest Friday, 17 Mar 1989 Volume 2 : Issue 65 Today's Topics: Notification Schemes The Jitters (dBase IV on PC) Re: Reply on notarization nVir2 on the Mac RE: File lock protection (Mac) --------------------------------------------------------------------------- Date: Tue, 14 Mar 89 15:38:09 EST From: Don Alvarez Subject: Notification Schemes Some further thoughts on the notorization scheme proposed by lambert@dockmaster.arpa (actually motorolla GEG) Mr. Lambert notes in his rebuttal to the first round of comments that they were uniformly negative. Since I was one of the people who submitted a negative comment, I think I am qualified to comment on this. Nowhere in your posting did you provide any details on what your scheme exactly is. You gave us a bunch of pointers to government and internet documents (including the definition of the RSA, as I recall), and you made your posting from dockmaster, so presumably we are supposed to accept all this as proof that you know what you are talking about. Unfortunately, it backfired. All you told us is that you had figured out how to solve all the world's computer security problems using notarizers, and that if we wanted to know how to do it, we should read your paper. No. There are probably at least a hundred papers written in the field of computer security every week, and none of us is going to go to the effort of looking this new one up just because you can site lots of documents like "(see ISO 7498-2)". If you want us to read your paper, tell us about it. How does your scheme work? Walk us through it. You say that software inherits notarizing. That's it. Then you blast what a bunch of other people have said. Of course people reacted negatively. Computer security is a hard problem, and there is enough nonsense written on the subject that all ideas are not automatically excepted as being valid. I started out planning to respond to your responses to peoples responses to your system, but I realized I had NO IDEA what your system is. I went back and re-read your two postings, and realized I STILL had no idea what you are suggesting. Perhaps you could take five minutes and write a short "A does this and then hands it to B who then computes a checksum and then does that with it. After this end users can do Z to their software to test its validity." I suspect the letters written to virus-l about your scheme would suddenly become MUCH more relavent. Also, I'm curious why you found it necessary to make your postings from Dockmaster. If Motorolla isn't willing to hook the people in its network groups up to the internet, I have a hard time believing that they understand what networking is all about. If you can't get virus-l at work, then that means you can't get email at work, and I just can't imagine a company hiring a bunch of network specialists and then not giving them access to the internet. I would enjoy continuing the discussion of your scheme, since it sounds like it might be interesting, but PLEASE tell us what your idea is. -Don + ----------------------------------------------------------- + | Don Alvarez MIT Center For Space Research | | boomer@SPACE.MIT.EDU 77 Massachusetts Ave 37-618 | | (617) 253-7457 Cambridge, MA 02139 | + ----------------------------------------------------------- + ------------------------------ Date: Tue, 14 Mar 89 16:12:32 EST From: Mignon Erixon-Stanford Subject: The Jitters (dBase IV on PC) An end user, recently having read about viruses, found some unexplained, unfamiliar files on his hard disk. Turns out that dBase IV has a known bug which leaves untidy file droppings with extensions of .TMP, .$ED, or .$VM. When you type them, you'll see YOUR data. They're safe to delete without losing data. Mignon Manin Erixon-Stanford [yes, the name's for real :-) ] Smithsonian Institution Washington, D.C. ------------------------------ Date: Tue, 14 Mar 89 15:10:00 -0800 From: James M Galvin Subject: Re: Reply on notarization > Public-key cryptography works fine when you have a method of > distributing the decryption key uncorrupted. But in the case of > a signature list coming from a bulletin board (for example), > using a public-key method just abstracts the problem one more step. > You STILL need a clean channel for transmitting the decryption key; > else anyone can modify a decrypted version of the signature file, > encrypt it again with another public key set and distribute the > new decryption key with the new signature file. This is a trivial > step for anyone who actually desires to modify the signature file.> > Public-key cryptography is just begging the question. And once > again, if you have this uncorruptable method for transmitting the > decryption key, you may as well transmit something simpler, like > file size, various checksums and crcs, or the entire program. It > again boils down to whom you can trust. You are confusing two separate issues. First, there is the use of cryptographic keys to achieve privacy, authentication and integrity. Second, there is the distribution and maintenance of those cryptographic keys. These are separate and distinct problems, and need not be considered together. You seem to be concerned about key distribution, so let me address that issue. Consider, if you will, distributing the public half of a public key set so ubiquitously, that a special distribution channel is not needed. This is roughly analogous to giving out your phone number; if it is not an unlisted number it is easily verified. Other than that, there are several well-defined protocols for key distribution. Check out the OSI Directory Services X.509 Recommendation for the best example. The bottom line is, key distribution requires a trusted entity. Once you trust that entity, you implicitly trust anything it gives you. You have no choice or the system does not work. Note, this is no different than in a "manual" system. If I do not bump into you personally and you give you my key, I am trusting someone to give it to you, i.e., a bonded courier service. Finally, let me address your comment about "transmitting something simpler". It does not work as simply as you suggest. For example, many checksums allow blocks of data to be swapped without being affected. Thus, file size and most checksums are not appropriate. As for sending the entire program, the uncorruptable method is typically prohibitive in terms of cost to use too often. That is why encryption is employed in the first place. The idea is to use the expensive channel infrequently for the keys and use the keys over insecure, inexpensive channels to achieve privacy, authentication and integrity. Jim ------------------------------ Date: Tue, 14 Mar 89 18:32 PST From: "Hervey Allen, U of O Comp Ctr (503)686-4394" Subject: nVir2 on the Mac I'm relatively new to this discussion and I have not seen any discussion of Macintosh viruses, but I thought I would place my query here anyway. Recently the the hard disk we use for our Appleshare network at the University of Oregon Computing Center was and is infected by a form of the nVir virus which we have not previously encountered. We have numerous public domain virus programs (AntiPan, Interfereon, VirusRX, VirusDetectve, Ferret, KillScoresUs, AntiVirus, and Vaccine) but none of them has been able to adequately deal with the strain of nVir we have encountered. For those of you who have dealt with Macintosh viruses before we usually run Interferon on the suspected disk and if an nVir virus is found we remove it with Anti- pan. The problem is that none of these programs was written for this new strain of nVir which is being called nVir2. Has anyone out there run into the nVir2 virus? And if so, does anyone know of a good method for getting rid of it. The virus will infect ResEdit and VirusRx if you attempt to run either one with a system that is already infected. The symptons of the virus include not letting a user print, telling the user they do not have enough memory to open applications, and locking the machine if Vaccine is installed. The virus appears to be much like the standard nVir virus which AntiPan can deal with, but more sophisticated so that AntiPan cannot delete it and VirusRX is immediately infected when run. We use a locked disk with a system and the virus utilities when trying to find and eradicate viruses. We have been able to get rid of it, but at the expense of removing and replacing numerous software packages and the System and Finder files from the System Folder (which includes moving fonts and desk accessories first). To us this virus appears completely new. I apologize in advance if all of you have already seen this numerous times, but if so please reply if you have had success in removing this strain of nVir. Hervey Allen Consultant University of Oregon Academic Computing Center Eugene, Oregon 97403 ------------------------------ Date: Tue, 14 Mar 89 14:27:30 EST From: Joe Simpson Subject: RE: File lock protection (Mac) Set the file locked bit will prevent a virus from using the high level write routines to change the file. This "ups the anti" and makes a virus that can defeate this protection more expensive to write. Most anti-virus techniques fall into this category. That is, you make the virus writer work harder to infect your system. To write to the locked file the virus writer on the Mac would probably have to use low level routines and do sector read/writes with manual update of the catalog. Joe McMahon (bless his heart) has assembled a very nice virus protection distribution service. TELL LISTSERV at SCFVM INDEX PUBLIC to see the catalog. I should note that this service covers Macintosh only. ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253