home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.256 < prev    next >
Text File  |  1995-01-03  |  14KB  |  318 lines

  1. VIRUS-L Digest   Friday,  8 Dec 1989    Volume 2 : Issue 256
  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. Virus Buster v2.00 (beta) (PC)
  17. Re: Signature programs
  18. WDEF Virus Alert (MAC)
  19. Video problem (PC)
  20. Network Virus Protection (Mac)
  21. WDEF Virus (Mac)
  22.  
  23. ---------------------------------------------------------------------------
  24.  
  25. Date:    Thu, 07 Dec 89 16:07:16 +0200
  26. From:    "Yuval Tal (972)-8-474592" <NYYUVAL@WEIZMANN.BITNET>
  27. Subject: Virus Buster v2.00 (beta) (PC)
  28.  
  29. Hello!
  30.  
  31. I am looking for a few beta-testers for the new version of Virus
  32. Buster.  The current version of VB is 1.10 and a new 2.00 will be
  33. released soon. I need people who have special hardware (large HD,
  34. special graphics adapter etc).  People who like to volunteer for this
  35. task should send e-mail to Yuval Tal (NYYUVAL@WEIZMANN.BITNET) or to
  36. one of the addresses written at the end of this letter.
  37.  
  38. Ok, here is some info about Virus Buster 1.10:
  39.  
  40. Virus Buster is an anti-viral software that was written in Israel by
  41. Uzi Apple (NYAPEL@WEIZMANN.BITNET) and by me. It can identify and
  42. remove about 15 viruses (version 2.00 will remove about 23) including:
  43. Data-crime, Jerusalem, 1st of april, Saratoga, FuManchu, Icelandic and
  44. more! Most important thing: It is PUBLIC DOMAIN! No fee charged! It
  45. has windows, statistics and much more. It will be soon available on
  46. the SIMTEL20 directories.
  47.  
  48. - -Yuval
  49.  
  50. +--------------------------------------------------------------------------+
  51. | BitNet:   NYYUVL@WEIZMANN        Domain: NYYUVAL@WEIZMANN.WEIZMANN.AC.IL |
  52. | InterNet: NYYUVAL%WEIZMANN.BITNET@CUNYVM.CUNY.EDU                        |
  53. +-----------------------------------+--------------------------------------+
  54. | Yuval Tal                         | Voice:   +972-8-474592               |
  55. | The Weizmann Institute Of Science | BBS:     +972-8-421842 * 20:00-7:00  |
  56. | Rehovot, Israel                   | FidoNet: 2:403/136         (CoSysop) |
  57. +-----------------------------------+--------------------------------------+
  58. |   "Always look on the bright side of life" *whistle*  -  Monty Phyton    |
  59. +--------------------------------------------------------------------------+
  60.  
  61. ------------------------------
  62.  
  63. Date:    Thu, 07 Dec 89 14:33:11 +0200
  64. From:    Y. Radai <RADAI1@HBUNOS.BITNET>
  65. Subject: Re: Signature programs
  66.  
  67.   Bob Bosen has posted a couple of articles on "signature" programs
  68. (I prefer to call them "checksum" programs).  I agree with some of
  69. what he has written, but disagree with other portions.  In V2 #249 he
  70. asks Steve Woronick:
  71. >                                              Are you saying you could
  72. >write or describe a virus that could infect a program but avoid
  73. >detection by an off-line ANSI X9.9-based message authentication code?
  74.  
  75.   I don't know what Steve's answer is, but mine is definitely YES, and
  76. I say that even though I know very little about the ANSI X9.9 algo-
  77. rithm.  Bob and many others, particularly those with backgrounds in
  78. cryptology, tend to emphasize the *algorithm*: X9.9 or DES or RSA
  79. is considered by the experts to be more secure than CRC, and that's
  80. all there is to it.  What they miss is the fact that what has to
  81. ensure security on a computer is not simply an algorithm, but rather a
  82. *program* which implements it in a given *operating system*.  And even
  83. a program based on the most sophisticated checksum algorithm in the
  84. world is circumventable if it is not written *very carefully*.
  85.   Take, for example, the PC checksum programs in the directory <MSDOS
  86. TROJAN-PRO> or <MSDOS.FILUTL> of the Simtel20 archives.  They all use
  87. a CRC (or in a few cases a more primitive) algorithm.  Suppose we
  88. choose one of them and replace the CRC algorithm by the ANSI X9.9
  89. algorithm.  Will that ensure security?  Far from it!  For one thing,
  90. most of these programs have no provision for checksumming the boot
  91. sector.  That means that despite the use of a sophisticated algorithm,
  92. these programs would be totally ineffective against boot-sector virus-
  93. es, and that includes a sizable percentage of existing viruses.
  94.   Boot-sector checksumming is available in a few of these programs,
  95. e.g. it was finally added to the FluShot+ program a few months ago.
  96. But to the best of my knowledge this program still does not have
  97. partition-record checksumming.  And that goes for almost all the other
  98. programs in those directories also (Sentry is a welcome exception).
  99.   But is checksumming the BS and PR all we need to worry about?  Defi-
  100. nitely not.  If we perform the checksumming when memory is infected by
  101. a Brain-type virus, even X9.9 won't detect any modification.
  102.   So now all we have to do is ensure that memory is uninfected when we
  103. perform the checksumming (by booting from a clean diskette, etc.).
  104. Right?  Wrong!  There are at least five other loopholes in PC-DOS/
  105. MS-DOS which a virus writer could exploit if the program is not care-
  106. fully written, all of which are independent of the checksum algorithm
  107. and do not depend on memory being infected.  (These have apparently
  108. never been used in any actual virus so far.)  Exploitation of such
  109. loopholes is much more practical (from the point of view of the virus
  110. writer) than the checksum-forging methods alluded to by several people
  111. in this forum, since they are independent of the checksum program and
  112. do not require any calculations (of checksums, polynomials, keys,
  113. etc.).  True, all of these loopholes can be blocked if the author of
  114. the checksum program thinks of them.  The trouble is not only that
  115. most authors do not, but also that there may be other loopholes which
  116. none of us has thought of yet.
  117.   The conclusion is that even a program based on the most sophistica-
  118. ted checksum algorithm in the world cannot be depended on to detect
  119. all infections.  Whether a given algorithm is secure depends heavily
  120. on how it's implemented as a *program* in a particular *system*.
  121.   If it's relevant, Bob, I would suggest that you raise this issue
  122. with the rest of the ANSI working group.  There's a small problem,
  123. however:  I have not publicly specified what these additional, more
  124. subtle loopholes are, since I feel it would be quite irresponsible of
  125. me to do so.  But somewhere around No. 89 on my list of 927 things to
  126. do is writing virus simulators to implement all, or at least most, of
  127. these loopholes.  If Bob or anyone else is willing to send me a PC
  128. program which implements X9.9 or any other signature algorithm which
  129. he thinks is secure, that would raise the priority of my writing at
  130. least one of these simulators, which I could then throw at the program
  131. in order to test whether it really is secure.
  132.  
  133.   Bob also asks:
  134. >                                                   Who can say whether
  135. >the more sophisticated viruses of the future will attempt to analyze
  136. >CRC signatures or target specific products that rely on CRC methods?
  137.  
  138.   Since he specifically mentions CRC methods, he is obviously not re-
  139. ferring to the types of loopholes to which I alluded above.  In V2
  140. #238 I gave arguments against the claim that CRC programs are circum-
  141. ventable in practice by checksum-forging methods, provided certain ob-
  142. vious precautions are taken.  Bob has given no reply to these argu-
  143. ments and I don't see how emphasis on *future* viruses affects them
  144. (except possibly as concerns the time required for the virus to do its
  145. work).  While I obviously can't prove it, my personal feeling is that
  146. *in practice* a CRC algorithm based on a randomly or personally chosen
  147. generator is, and will remain, just as secure as any more sophistica-
  148. ted algorithm (if the CRC base and program are kept offline) and pro-
  149. bably a lot faster.  In any case, the most important thing is the pro-
  150. gram, not the algorithm.
  151.  
  152.                                      Y. Radai
  153.                                      Hebrew Univ. of Jerusalem, Israel
  154.                                      RADAI1@HBUNOS.BITNET
  155.  
  156. ------------------------------
  157.  
  158. Date:    Thu, 07 Dec 89 10:55:38 -0700
  159. From:    Pete Troxell <troxell@INLOTTO.DEN.MMC.COM>
  160. Subject: WDEF Virus Alert (MAC)
  161.  
  162. This is being cross-posted from comp.sys.mac. The original article is
  163. by John Norstad of Northwestern University:
  164.  
  165. A new Macintosh virus named "WDEF" has been discovered in Belgium,
  166. at Northwestern University, and at the University of Texas.
  167.  
  168. The WDEF virus infects the invisible "Desktop" files used by the
  169. Finder.  Every Macintosh disk has one of these files (hard drives
  170. and floppies).  The virus spreads from Desktop file to Desktop
  171. file, but it does not infect applications, data files, or system
  172. files.
  173.  
  174. The virus does not intentionally try to do any damage.  In fact,
  175. it doesn't do anything except spread from disk to disk.
  176.  
  177. Due to a bug, the virus causes Mac IIcis to crash.  We have also
  178. noticed unusually frequent crashes on infected Mac IIcxs, and
  179. severe performance problems with infected AppleShare servers.
  180. There are also other bugs in the virus which could cause problems.
  181.  
  182. You do not have to run a program for the virus to spread.
  183.  
  184. Unlike most of the other Mac viruses, the WDEF virus is not spread
  185. via the sharing and distribution of programs, but rather via the
  186. sharing and distribution of disks, usually floppy disks.
  187.  
  188. You can eliminate the virus from a disk by rebuilding the desktop
  189. file (hold down the Command and Option keys while booting or while
  190. inserting a floppy).
  191.  
  192. Jeff Shulman, the author of Virus Detective 3.1, recommends adding
  193. the following search string to detect the virus:
  194.  
  195.     Creator=ERIK & Resource WDEF & Any
  196.  
  197. Virus Detective can also be used to remove the virus - click on
  198. the "Remove" button whenever the search string is matched.  This
  199. only works if you are not using MultiFinder, and if you are
  200. running some program other than the Finder.  Don't try this with
  201. the other viruses - Virus Detective can only repair WDEF
  202. infections, not infections by the other known Macintosh viruses.
  203.  
  204. As far as we know, Virus Detective is the only virus-fighting tool
  205. which can detect the new WDEF virus.
  206.  
  207. Unfortunately, the virus manages to avoid detection by all of the
  208. popular protection INITs, including Vaccine 1.0.1, GateKeeper
  209. 1.1.1, SAM Intercept 1.10, and Virex INIT 1.12.
  210.  
  211. Disinfectant 1.3, Virus Rx 1.5, SAM Virus Clinic 1.10, and Virex
  212. 2.12 also all fail to detect the virus.
  213.  
  214. We expect that many of the virus-fighting programs mentioned above
  215. will be updated soon to deal properly with the new WDEF virus.
  216.  
  217. John Norstad
  218. Academic Computing and Network Services
  219. Northwestern University
  220. 2129 Sheridan Road
  221. Evanston, IL 60208
  222.  
  223. jln@acns.nwu.edu
  224.  
  225. - --
  226. Peter Troxell
  227. NET:     ncar!dinl!troxell
  228. ARPA:    Troxell@Dockmaster.ARPA
  229. US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260,
  230.          Denver, CO 80201-1260
  231. Phone:   (303) 971-7928
  232.  
  233. ------------------------------
  234.  
  235. Date:    07 Dec 89 20:55:51 +0000
  236. From:    tte@metaware.metaware.com (Thuan-Tit Ewe)
  237. Subject: Video problem (PC)
  238.  
  239. Regarding your posting, I know of a virus which will do just such a thing.
  240. After disassemblying Jerusalem B virus, I saw code in there triggered by
  241. the clock interrupt that will scroll a region of the screen some two lines
  242. up.
  243.  
  244. Your best bet is to use any anti-viral program to check your system and
  245. make sure it's not affected. Also, to see if it a virus attact:
  246.  
  247. 1. Get a good copy of any small program from a floppy. (Maybe debug.com from
  248.    your DOS distribution)
  249. 2. Note its size
  250. 3. Run the program that will cause the screen scroll. (Or any wierd problem)
  251. 4. Exit program on step 3, and execute the small program.
  252. 5. Exit the small program and check to see if the size increased.
  253.  
  254. If it does, chances are very, very, very good that you have a virus problem!
  255.  
  256. Of course, if the small program has already been infected, you won't see
  257. any size increase.
  258.  
  259. Thuan-Tit Ewe                   MetaWare Inc
  260. tte@metaware.com                (408) 476-8936
  261. {uunet|ucscc|acad}!metaware!tte
  262.  
  263. ------------------------------
  264.  
  265. Date:    Thu, 07 Dec 89 15:47:27 -0500
  266. From:    "Gregory E. Gilbert" <C0195@UNIVSCVM.BITNET>
  267. Subject: Network Virus Protection (Mac)
  268.  
  269. Is there any freeware that will provide virus protection when using a
  270. network such as AppleShare or TOPS?  I know SAM will work fine.  Will
  271. Gatekeeper or Vaccine provide adequate protection?  Will Disinfectant
  272. provide adequate diagnosing capabilities?
  273.  
  274. Greg
  275.  
  276. Postal address:   Gregory E. Gilbert
  277.                   Computer Services Division
  278.                   University of South Carolina
  279.                   Columbia, South Carolina   USA   29208
  280.                   (803) 777-6015
  281. Acknowledge-To: <C0195@UNIVSCVM>
  282.  
  283. ------------------------------
  284.  
  285. Date:    Fri, 08 Dec 89 11:42:58 -0500
  286. From:    "Gregory E. Gilbert" <C0195@UNIVSCVM.BITNET>
  287. Subject: WDEF Virus (Mac)
  288.  
  289. Recently there was a posting on VALERT-L about a new virues, WDEF.  In the
  290. alert it is mentioned that:
  291.  
  292. (stuff deleted)
  293.  
  294. "Jeff Shulman, the author of Virus Detective 3.1, recommends adding the
  295. following search string to detect the virus:
  296.  
  297. CREATOR=ERIK & Resource WDEF & Any
  298.  
  299. Virus Detective can also be used to remove the virus ......"
  300.  
  301. Where or to what do we add the "following search string".  Please
  302. pardon my ignorance.
  303.  
  304. Greg
  305.  
  306. Postal address:   Gregory E. Gilbert
  307.                   Computer Services Division
  308.                   University of South Carolina
  309.                   Columbia, South Carolina   USA   29208
  310.                   (803) 777-6015
  311. Acknowledge-To: <C0195@UNIVSCVM>
  312.  
  313. ------------------------------
  314.  
  315. End of VIRUS-L Digest
  316. *********************
  317. Downloaded From P-80 International Information Systems 304-744-2253
  318.