home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.65 < prev    next >
Text File  |  1995-01-03  |  10KB  |  223 lines
  1. VIRUS-L Digest              Friday, 17 Mar 1989         Volume 2 : Issue 65
  2.  
  3. Today's Topics:
  4. Notification Schemes
  5. The Jitters (dBase IV on PC)
  6. Re: Reply on notarization
  7. nVir2 on the Mac
  8. RE: File lock protection (Mac)
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date: Tue, 14 Mar 89 15:38:09 EST
  13. From: Don Alvarez <boomer@space.mit.edu>
  14. Subject: Notification Schemes
  15.  
  16. Some further thoughts on the notorization scheme proposed by
  17. lambert@dockmaster.arpa (actually motorolla GEG)
  18.  
  19. Mr. Lambert notes in his rebuttal to the first round of comments that
  20. they were uniformly negative.  Since I was one of the people who
  21. submitted a negative comment, I think I am qualified to comment on
  22. this.  Nowhere in your posting did you provide any details on what
  23. your scheme exactly is.  You gave us a bunch of pointers to government
  24. and internet documents (including the definition of the RSA, as I
  25. recall), and you made your posting from dockmaster, so presumably we
  26. are supposed to accept all this as proof that you know what you are
  27. talking about.  Unfortunately, it backfired.  All you told us is that
  28. you had figured out how to solve all the world's computer security
  29. problems using notarizers, and that if we wanted to know how to do it,
  30. we should read your paper.  No.  There are probably at least a hundred
  31. papers written in the field of computer security every week, and none
  32. of us is going to go to the effort of looking this new one up just
  33. because you can site lots of documents like "(see ISO 7498-2)".  If
  34. you want us to read your paper, tell us about it.  How does your
  35. scheme work?  Walk us through it.  You say that software inherits
  36. notarizing. That's it.  Then you blast what a bunch of other people
  37. have said.  Of course people reacted negatively.  Computer security is
  38. a hard problem, and there is enough nonsense written on the subject
  39. that all ideas are not automatically excepted as being valid.
  40.  
  41. I started out planning to respond to your responses to peoples
  42. responses to your system, but I realized I had NO IDEA what your
  43. system is.  I went back and re-read your two postings, and realized I
  44. STILL had no idea what you are suggesting.  Perhaps you could take
  45. five minutes and write a short "A does this and then hands it to B who
  46. then computes a checksum and then does that with it.  After this end
  47. users can do Z to their software to test its validity."  I suspect the
  48. letters written to virus-l about your scheme would suddenly become
  49. MUCH more relavent.
  50.  
  51. Also, I'm curious why you found it necessary to make your postings
  52. from Dockmaster.  If Motorolla isn't willing to hook the people in its
  53. network groups up to the internet, I have a hard time believing that
  54. they understand what networking is all about.  If you can't get
  55. virus-l at work, then that means you can't get email at work, and I
  56. just can't imagine a company hiring a bunch of network specialists and
  57. then not giving them access to the internet.
  58.  
  59. I would enjoy continuing the discussion of your scheme, since it
  60. sounds like it might be interesting, but PLEASE tell us what your idea
  61. is.
  62.  
  63.                 -Don
  64.  
  65.      + ----------------------------------------------------------- +
  66.      |   Don Alvarez               MIT Center For Space Research   |
  67.      |   boomer@SPACE.MIT.EDU      77 Massachusetts Ave   37-618   |
  68.      |   (617) 253-7457            Cambridge, MA 02139             |
  69.      + ----------------------------------------------------------- +
  70.  
  71. ------------------------------
  72.  
  73. Date:         Tue, 14 Mar 89 16:12:32 EST
  74. From:         Mignon Erixon-Stanford <IRMSS907@SIVM.BITNET>
  75. Subject:      The Jitters (dBase IV on PC)
  76.  
  77. An end user, recently having read about viruses, found some
  78. unexplained, unfamiliar files on his hard disk.  Turns out that
  79. dBase IV has a known bug which leaves untidy file droppings
  80. with extensions of .TMP,  .$ED,  or  .$VM.  When you type them,
  81. you'll see YOUR data.  They're safe to delete without losing data.
  82.  
  83. Mignon Manin Erixon-Stanford   [yes, the name's for real :-) ]
  84. Smithsonian Institution
  85. Washington, D.C.
  86.  
  87. ------------------------------
  88.  
  89. Date: Tue, 14 Mar 89 15:10:00 -0800
  90. From: James M Galvin <galvin@TWG.COM>
  91. Subject: Re: Reply on notarization
  92.  
  93. > Public-key cryptography works fine when you have a method of
  94. > distributing the decryption key uncorrupted.  But in the case of
  95. > a signature list coming from a bulletin board (for example),
  96. > using a public-key method just abstracts the problem one more step.
  97. > You STILL need a clean channel for transmitting the decryption key;
  98. > else anyone can modify a decrypted version of the signature file,
  99. > encrypt it again with another public key set and distribute the
  100. > new decryption key with the new signature file.  This is a trivial
  101. > step for anyone who actually desires to modify the signature file.>
  102. > Public-key cryptography is just begging the question.  And once
  103. > again, if you have this uncorruptable method for transmitting the
  104. > decryption key, you may as well transmit something simpler, like
  105. > file size, various checksums and crcs, or the entire program.  It
  106. > again boils down to whom you can trust.
  107.  
  108. You are confusing two separate issues.  First, there is the use of
  109. cryptographic keys to achieve privacy, authentication and integrity.
  110. Second, there is the distribution and maintenance of those
  111. cryptographic keys.  These are separate and distinct problems, and
  112. need not be considered together.
  113.  
  114. You seem to be concerned about key distribution, so let me address
  115. that issue.  Consider, if you will, distributing the public half of a
  116. public key set so ubiquitously, that a special distribution channel is
  117. not needed.  This is roughly analogous to giving out your phone
  118. number; if it is not an unlisted number it is easily verified.
  119.  
  120. Other than that, there are several well-defined protocols for key
  121. distribution.  Check out the OSI Directory Services X.509
  122. Recommendation for the best example.
  123.  
  124. The bottom line is, key distribution requires a trusted entity.  Once
  125. you trust that entity, you implicitly trust anything it gives you.
  126. You have no choice or the system does not work.  Note, this is no
  127. different than in a "manual" system.  If I do not bump into you
  128. personally and you give you my key, I am trusting someone to give it
  129. to you, i.e., a bonded courier service.
  130.  
  131. Finally, let me address your comment about "transmitting something
  132. simpler".  It does not work as simply as you suggest.  For example,
  133. many checksums allow blocks of data to be swapped without being
  134. affected.  Thus, file size and most checksums are not appropriate.
  135.  
  136. As for sending the entire program, the uncorruptable method is
  137. typically prohibitive in terms of cost to use too often.  That is why
  138. encryption is employed in the first place.  The idea is to use the
  139. expensive channel infrequently for the keys and use the keys over
  140. insecure, inexpensive channels to achieve privacy, authentication and
  141. integrity.
  142.  
  143. Jim
  144.  
  145. ------------------------------
  146.  
  147. Date: Tue, 14 Mar 89 18:32 PST
  148. From: "Hervey Allen, U of O Comp Ctr (503)686-4394" <HALLEN@oregon.bitnet>
  149. Subject: nVir2 on the Mac
  150.  
  151. I'm relatively new to this discussion and I have not seen any
  152. discussion of Macintosh viruses, but I thought I would place my query
  153. here anyway.
  154.  
  155. Recently the the hard disk we use for our Appleshare network at the
  156. University of Oregon Computing Center was and is infected by a form
  157. of the nVir virus which we have not previously encountered.  We have
  158. numerous public domain virus programs (AntiPan, Interfereon, VirusRX,
  159. VirusDetectve, Ferret, KillScoresUs, AntiVirus, and Vaccine) but none
  160. of them has been able to adequately deal with the strain of nVir we
  161. have encountered.  For those of you who have dealt with Macintosh
  162. viruses before we usually run Interferon on the suspected disk and if
  163. an nVir virus is found we remove it with Anti- pan.  The problem is
  164. that none of these programs was written for this new strain of nVir
  165. which is being called nVir2.
  166.  
  167. Has anyone out there run into the nVir2 virus? And if so, does anyone
  168. know of a good method for getting rid of it.  The virus will infect
  169. ResEdit and VirusRx if you attempt to run either one with a system
  170. that is already infected.  The symptons of the virus include not
  171. letting a user print, telling the user they do not have enough memory
  172. to open applications, and locking the machine if Vaccine is installed.
  173. The virus appears to be much like the standard nVir virus which
  174. AntiPan can deal with, but more sophisticated so that AntiPan cannot
  175. delete it and VirusRX is immediately infected when run.  We use a
  176. locked disk with a system and the virus utilities when trying to find
  177. and eradicate viruses.
  178.  
  179. We have been able to get rid of it, but at the expense of removing and
  180. replacing numerous software packages and the System and Finder files
  181. from the System Folder (which includes moving fonts and desk
  182. accessories first).
  183.  
  184. To us this virus appears completely new.  I apologize in advance if
  185. all of you have already seen this numerous times, but if so please
  186. reply if you have had success in removing this strain of nVir.
  187.  
  188. Hervey Allen
  189.  
  190. Consultant
  191. University of Oregon Academic Computing Center
  192. Eugene, Oregon   97403
  193.  
  194. ------------------------------
  195.  
  196. Date:         Tue, 14 Mar 89 14:27:30 EST
  197. From:         Joe Simpson <JS05STAF@MIAMIU.BITNET>
  198. Subject:      RE: File lock protection (Mac)
  199.  
  200. Set the file locked bit will prevent a virus from using the high level
  201. write routines to change the file.
  202.  
  203. This "ups the anti" and makes a virus that can defeate this protection
  204. more expensive to write.
  205.  
  206. Most anti-virus techniques fall into this category.  That is, you
  207. make the virus writer work harder to infect your system.
  208.  
  209. To write to the locked file the virus writer on the Mac would probably
  210. have to use low level routines and do sector read/writes with manual
  211. update of the catalog.
  212.  
  213. Joe McMahon (bless his heart) has assembled a very nice virus
  214. protection distribution service.  TELL LISTSERV at SCFVM INDEX PUBLIC
  215. to see the catalog.  I should note that this service covers Macintosh
  216. only.
  217.  
  218. ------------------------------
  219.  
  220. End of VIRUS-L Digest
  221. *********************
  222. Downloaded From P-80 International Information Systems 304-744-2253
  223.