home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.230 < prev    next >
Text File  |  1995-01-03  |  9KB  |  213 lines
  1. VIRUS-L Digest   Friday,  3 Nov 1989    Volume 2 : Issue 230
  2.  
  3. VIRUS-L is a moderated, digested mail forum for discussing computer
  4. virus issues; comp.virus is a non-digested Usenet counterpart.
  5. Discussions are not limited to any one hardware/software platform -
  6. diversity is welcomed.  Contributions should be relevant, concise,
  7. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  8. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  9. anti-virus, document, and back-issue archives is distributed
  10. periodically on the list.  Administrative mail (comments, suggestions,
  11. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  12.  - Ken van Wyk
  13.  
  14. Today's Topics:
  15.  
  16. CRC checking
  17. Re: Checksum programs
  18. Re: Self-checking programs (PC)
  19. Re:Virus source available in Toronto
  20. DBASE Virus and SCANV47 (PC)
  21. decompiling a virus
  22.  
  23. ---------------------------------------------------------------------------
  24.  
  25. Date:    Wed, 01 Nov 89 00:00:00 +0000
  26. From:    "Prof Arthur I. Larky" <AIL0@LEHIGH.BITNET>
  27. Subject: CRC checking
  28.  
  29.              A CRC will work if you:
  30.  
  31.              (1) Keep the polynomial secret and personal.
  32.  
  33.              (2)   Keep   the  comparison  information  secret  and
  34.              personal.
  35.  
  36.              You can accomplish (1) by having the checker  ask  for  the
  37.         polynomial  (or  some  portion of it) when you boot up and start
  38.         the checking.  The checker should NOT store  the  polynomial  on
  39.         disk anywhere.
  40.  
  41.              You  can  accomplish  (2) by having the checker ask for the
  42.         check file name and/or path when  you  boot  up  and  start  the
  43.         checking.
  44.  
  45.              Both  of  these  are a pain to do, but losing everything on
  46.         your hard drive is much more of a pain.  Of course,  you  should
  47.         still do regular backups (I do lots of program development, so I
  48.         back  up  everything  on floppy as soon as I create it) and have
  49.         someone's program watching your disk for you.
  50.  
  51.              The basic rule  is:  Be  Different!   MSDOS  is  vulnerable
  52.         because  it is so well-known how to write lethal things to disk.
  53.         If you name your checksum file "Checksum.fil", you  are  looking
  54.         for  trouble!   I know I can find a name and a sub-directory for
  55.         it that I wouldn't recognize a month later.
  56.  
  57.                                       Art
  58.                                    CSEE Dept
  59.                                Lehigh University
  60.                                  Bethlehem, PA
  61.  
  62.  
  63.         Disclaimer, disclaimer, disclaimer
  64.  
  65. ------------------------------
  66.  
  67. Date:    01 Nov 89 20:53:10 +0000
  68. From:    len@csd4.csd.uwm.edu (Leonard P Levine)
  69. Subject: Re: Checksum programs
  70.  
  71. kerchen@iris.ucdavis.edu (Paul Kerchen) writes:
  72. > This point brings up a problem which is common to most checksumming
  73. > solutions: where does one store these checksums and their keys?  If
  74. > they are stored on disk, they are vulnerable to attack just like
  75. > programs.  That is, a virus could infect the program and then update
  76. > its checksum, since the key must be somewhere on disk as well (unless
  77. > the user enters it every time they compute a checksum--yecch!) and one
  78. > must assume that the checksum algorithm is known.
  79.  
  80. The checksum program and the checksum should be stored in a place that is
  81. different on each machine.  Furthermore, there is no special "best"
  82. crc or testing algorithm, many will do with varying polynomials.
  83.  
  84. A satisfactory system is one in which each user can use a polynomial
  85. of his/her choice and where the list of files and their crc's
  86. (for example) is stored in some arbitrary location.  No virus writer
  87. will be looking for YOU, rather just a collection of systems that
  88. are alike enough to infect.
  89.  
  90. When dutch elm disease comes around, you should look like an oak tree.
  91. Be different enough so that only a specific attack can defeat your
  92. defences, not just some attempt to infiltrate command.com.
  93.  
  94. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  95. | Leonard P. Levine                  e-mail len@evax.cs.uwm.edu |
  96. | Professor, Computer Science             Office (414) 229-5170 |
  97. | University of Wisconsin-Milwaukee       Home   (414) 962-4719 |
  98. | Milwaukee, WI 53201 U.S.A.              FAX    (414) 229-6958 |
  99. + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
  100.  
  101. ------------------------------
  102.  
  103. Date:    02 Nov 89 02:02:35 +0000
  104. From:    berman-andrew@YALE.EDU (Andrew P. Berman)
  105. Subject: Re: Self-checking programs (PC anti-virus protection)
  106.  
  107. In article <0006.8911011255.AA25780@ge.sei.cmu.edu> leif@ambra.dk (Leif Andrew
  108. Rump) writes:
  109. >If a virus killer can patch a program so can a virus! Exactly as virus
  110. >detectors is able to find a virus by looking at the code so is the
  111. >virus able to detect the virus killer and disable it! That's life!!
  112.  
  113. I wonder if that's actually the case.  Consider that most of the virus'
  114. created so far have been under 3 kilobytes.  A virus must be somewhat
  115. small to avoid detection- a 40k patch to every program could be detected
  116. visually by the user with a 1 meg floppy disk.  Perhaps a very complex
  117. virus killer could patch a program in such a way that only a very complex
  118. virus could unpatch it-  a patching algorithm X with a proof on the order of
  119. "patch algorithm X cannot be unpatched by a program with less than 100k" or
  120. something like that might do some good.
  121.   Or, perhaps we could design patches that might be unpatchable by a
  122. short virus, but would take a great deal of time. We're not really too
  123. concerned about length of time it takes to patch, since that only would
  124. occur once for each program.  Thus, a patching algorithm X which can
  125. be proven to be computationally-hard to unpatch would be effective because
  126. the virus might be required to take up a great deal of computer time,
  127. again providing a means to alert the user.
  128.  
  129. Frankly, I find the stuff fascinating... I think there's some
  130. theoretical computing issues involved here, but hey, what do I know, I'm
  131. only a grad student.
  132.  
  133.  
  134. Andrew P. Berman
  135. berman@yale.edu
  136.  
  137. ------------------------------
  138.  
  139. Date:    Thu, 02 Nov 89 18:47:07 +0100
  140. From:    fbihh!swimmer@uunet.UU.NET (Morton Swimmer)
  141. Subject: Re:Virus source available in Toronto
  142.  
  143. kelly@uts.amdahl.com (Kelly Goen) writes:
  144.  
  145. >Yes it is indeed true that viral sources are published in several
  146. >areas... however "Viruses , A high Tech disease" published only
  147. >overwriting viruses!! more similar to a logic bomb as when they infect
  148. >the target executable the file is immediately destroyed(VERY EASY to
  149. >detect) by the overwriting process. However any COMPETANT Assembly
  150. >coder can manufacture far more unobtrusive viruses if he just thinks
  151. >about it!! the published sources working or non working are really not
  152. >that much of a threat...
  153.  
  154. Oh yes they are!
  155. It is very much easier to start from a working source
  156. than to start from scratch. Irrespective if you are
  157. "competant" or not. Just take the source, think of
  158. something and implement it. It will take you far less
  159. time, and the inhibition is far less. This is exactly
  160. what happened to one of the viruses published in
  161. R**** B*****'s book. Not long afterwards, presto! we
  162. had the Vienna (648) virus!
  163. Granted, its just a small chip off the block, but
  164. you must try everything to win this war.
  165.  
  166. Cheers, Morton
  167.  
  168. ------------------------------
  169.  
  170. Date:    Thu, 02 Nov 89 15:09:50 -0800
  171. From:    portal!cup.portal.com!Alan_J_Roberts@Sun.COM
  172. Subject: DBASE Virus and SCANV47 (PC)
  173.  
  174.         A number of folks have looked at the DBASE virus (Ross
  175. Greenberg's discovery), including Joe Hirst, Steffan Campbell and T.B.
  176. Allen, and the general consensus is that the virus is very similar in
  177. style to the TYPO virus (The COM version).  If the author of these two
  178. viruses is one and the same person, then perhaps the DBASE author has
  179. not completely been "re-habilitated" as Ross Greenberg has suggested.
  180. If this is the case, then the DBASE virus may have been placed into
  181. the public domain (and would indeed account for the inexplicable DBASE
  182. problem reports that have been received over many months by the CVIA).
  183. Accordingly, SCAN V47 has been updated to include a check for this
  184. virus.  Better safe than sorry.
  185.  
  186. Alan
  187.  
  188. ------------------------------
  189.  
  190. Date:    Thu, 02 Nov 89 22:30:19 -0800
  191. From:    ames!dhw68k.cts.com!stein@apple.com (Rick 'Transputer' Stein)
  192. Subject: decompiling a virus
  193.  
  194. I just finished reading "With Microscope and Tweezers: An Analysis of
  195. the Internet Virus of Nov. 1988" by Eichin and Rochlis in the
  196. Proceedings of the 1989 IEEE Symposium on Security and Privacy.  They
  197. discuss the decompilation process but only in a vague sense.  What is
  198. decompilation?
  199.  
  200. Do you actually have to take apart a core dump, find the opcodes,
  201. operands, and build a hi-level pseudocode from this?  Is there an
  202. automated tool, or hunk of software which decompiles images for you?
  203. How do you detect a virus in core with a "process interagator" if
  204. something like this exists.
  205.  
  206. - --rick
  207.  
  208. ------------------------------
  209.  
  210. End of VIRUS-L Digest
  211. *********************
  212. Downloaded From P-80 International Information Systems 304-744-2253
  213.