home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl3 / virusl3.50 < prev    next >
Text File  |  1995-01-03  |  16KB  |  340 lines

  1. VIRUS-L Digest   Tuesday, 27 Feb 1990    Volume 3 : Issue 50
  2.  
  3. Today's Topics:
  4.  
  5. CoTRA virus sig meeting
  6. re: Virus signatures & IBM virus scanner (PC)
  7. Stoned Virus (PC)
  8. Re: NYT Bestseller
  9. Tried 800 number for Virus Conference
  10. Virus Disinfections (PC)
  11. 1701/1704 Ver. B virus and SCAN/CLEAN Ver. 2.7 V57 (PC)
  12. Posting scan signatures.
  13. Ping Pong Virus (PC)
  14.  
  15. VIRUS-L is a moderated, digested mail forum for discussing computer
  16. virus issues; comp.virus is a non-digested Usenet counterpart.
  17. Discussions are not limited to any one hardware/software platform -
  18. diversity is welcomed.  Contributions should be relevant, concise,
  19. polite, etc.  Please sign submissions with your real name.  Send
  20. contributions to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's equivalent to
  21. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  22. anti-virus, documentation, and back-issue archives is distributed
  23. periodically on the list.  Administrative mail (comments, suggestions,
  24. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  25.  
  26.    Ken van Wyk
  27.    Moderator, VIRUS-L/comp.virus
  28.    Technical Coordinator, Computer Emergency Response Team
  29.    Software Engineering Institute
  30.    Carnegie Mellon University
  31.    cert@CERT.SEI.CMU.EDU (monitored during business hours)
  32.    (412) 268-7090        (answers 24 hour a day)
  33.  
  34. ---------------------------------------------------------------------------
  35.  
  36. Date:    Mon, 26 Feb 90 11:23:47 -0000
  37. From:    David.J.Ferbrache <davidf@CS.HW.AC.UK>
  38. Subject: CoTRA virus sig meeting
  39.  
  40. A number of British readers may be aware that the Computer Threat
  41. Research Association was formed recently to address a wide range of
  42. computer security and integrity issues, including the establishment of
  43. a central library of viral materials and an active research group for
  44. work on viruses.
  45.  
  46. As virus SIG co-ordinator I would like to arrange a meeting of the SIG
  47. in the last week of March, issues I hope to discuss are establishment
  48. of:
  49.  
  50. 1. A central UK library of viral materials available to all bona-fide
  51.    virus researchers (fortunately the definition of bona-fide is being
  52.    tackled by another committee)
  53. 2. A number of sites with a test bed set of viruses for evaluation
  54.    of commercial and public domain anti-viral products
  55. 3. A network of formal or informal connections to deal with future occurences
  56.    of bulk mailed trojan horses, major new viral strains or network worms
  57.  
  58. The AIDS trojan horse clearly indicated the lack of a well organised
  59. network of virus/trojan workers in the field. The response, while
  60. enthusiastic, did duplicate much effort accross a number of separate
  61. sites. While I realise that commercial considerations often temper the
  62. distribution of information between workers in the field, I feel that
  63. issues such as the AIDS trojan must circumvent industrial
  64. confidentiality to allow a sharing of information, and division of
  65. workload. With complex disassemblies it is likely that details of
  66. protection mechanisms (particularly self-modifying code) may be missed
  67. by one researcher and detected by another. The cross-checking of
  68. disassemblies is vital to the accuracy of the final product.
  69.  
  70. The Internet worm caused formalisation of the "old-boy" network,
  71. resulting in the creation of an excellent rapid response system (CERT)
  72. with formal links with established experts in the field. I hope that
  73. such a structure will evolve in the UK, preferably with government
  74. recognition of the important role that such an organisation will play
  75. in the security and integrity of personal and mainframe computer
  76. systems.
  77.  
  78. I would be interested in any feedback on the above comments
  79. (preferably constructive criticism). Hopefully such a reporting
  80. network will not be restricted to member of CoTRA but will include all
  81. workers in the field (academic, commercial and governmental).
  82.  
  83. - -----------------------------------------------------------------------------
  84. \c-
  85. Dave Ferbrache                            Internet   <davidf@cs.hw.ac.uk>
  86. Dept of computer science                  Janet      <davidf@uk.ac.hw.cs>
  87. Heriot-Watt University                    UUCP       ..!mcvax!hwcs!davidf
  88. 79 Grassmarket                            Telephone  +44 31-225-6465 ext 553
  89. Edinburgh, United Kingdom                 Facsimile  +44 31-220-4277
  90. EH1 2HJ                                   BIX/CIX    dferbrache
  91. - -----------------------------------------------------------------------------
  92. \c-
  93.  
  94. ------------------------------
  95.  
  96. Date:    26 Feb 90 00:00:00 +0000
  97. From:    "David.M..Chess" <CHESS@YKTVMV.BITNET>
  98. Subject: re: Virus signatures & IBM virus scanner (PC)
  99.  
  100. Kevin_Haney@NIHDCRT.BITNET writes:
  101.  
  102. > With regard to Gerry Santoro's question about the IBM virus scanning
  103. > program, the author, Bill Arnold, is constantly updating the program,
  104. > improving its performance and including new viral signatures.  The
  105. > current version is 1.37 which scans for 58 different signatures and I
  106. > assume that if you have an older one you can get an update from IBM.
  107.  
  108. IBM has made only one version of The IBM Virus Scanning Program
  109. available to the public; this is version 1.0, that was released in
  110. September of 1989.  Any other versions of the IBM program are marked
  111. IBM Internal Use Only, and are not available to the public at this
  112. time.  We definitely urge people *not* to use any program marked IBM
  113. Internal Use Only (except for IBM internal use, of course, or if you
  114. have a specific agreement signed with IBM allowing you to use it).
  115.  
  116. Dave Chess
  117. IBM T. J. Watson Research Center
  118.  
  119. ------------------------------
  120.  
  121. Date:    26 Feb 90 20:47:26 +0000
  122. From:    moncol!c2810@princeton.edu (SATYAJIT CHATTERJEE)
  123. Subject: Stoned Virus (PC)
  124.  
  125. We discovered the Stoned Virus in our PC's recently. Does anyone have
  126. any suggestions on how to get rid of this. We have hundreds of users
  127. who have their own floppies, most of them infected I suppose. It would
  128. be difficult to call them all in. Is there some way of automating
  129. this? Any suggestions will be appreciated.
  130.  
  131. ------------------------------
  132.  
  133. Date:    26 Feb 90 14:56:00 -0500
  134. From:    "zmudzinski, thomas" <zmudzinskit@imo-uvax.dca.mil>
  135. Subject: Re: NYT Bestseller
  136.  
  137. Cliff, I read your note in VIRUS-L Digest; Volume 3 : Issue 49
  138.  
  139. >> The Cuckoo's Egg has made it onto the NY Times bestseller list.
  140. >> I'm amazed that so many people would be interested
  141. >> in our computer networks, viruses, and nasty animals in our systems.
  142.  
  143. Bad news, Cliff --
  144.  
  145. Yesterday I visited a discount book outlet, BOOKS-A-MILLION, and
  146. there, big as life, was a pile of _The_Cuckoo's_Egg_'s, $13.95.
  147. (Why couldn't I have gotten that price when I bought four copies?)
  148.  
  149. :{D
  150.  
  151. Tom Zmudzinski     |   Sic Transit Gloria Mundi,
  152. DCS Data Systems   |   which Murphy translates as
  153. McLean, VA         |   "Tuesday will be worse".
  154.  
  155. ------------------------------
  156.  
  157. Date:    Mon, 26 Feb 90 16:29:29 -0500
  158. From:    Peter Jones <MAINT@UQAM.BITNET>
  159. Subject: Tried 800 number for Virus Conference
  160.  
  161. I just tried calling the number (800)-835-2246 about the upcoming
  162. virus conference. The lady who answered asked be who I was calling
  163. *for*, not from.  I repeated the number verbally; she said she
  164. couldn't tell what company I was trying to reach because their
  165. computers were down, and she had tried and failed to find the
  166. information another way. (Yes, I'm going to submit this item to
  167. RISKS.)
  168.  
  169. I had intended to suggest that detailed conference information be
  170. posted on the VIRUS-L.
  171.  
  172. Peter Jones     MAINT@UQAM     (514)-987-3542
  173. "Life's too short to try and fill up every minute of it" :-)
  174.  
  175. ------------------------------
  176.  
  177. Date:    Mon, 26 Feb 90 15:07:18 -0800
  178. From:    Alan_J_Roberts@cup.portal.com
  179. Subject: Virus Disinfections (PC)
  180.  
  181.           This is a forward from John McAfee:
  182. =================================================================
  183.  
  184.           A number of Virus-L entries over the past couple of months
  185. have discussed virus disinfection issues and the problems with
  186. disinfecting certain viruses.  Vesselin Bontchev yesterday wrote:
  187.  
  188. >I spoke with David Chess (at IBM) and he prefers the "delete the
  189. >infected file and restore them from backups" method.  But have in
  190. >mind, that the guy from Taiwan is in trouble --- and may not have
  191. >appropriate backups.
  192.  
  193.           I understand Vesselin's point, but in general I favor Dave's
  194. approach.  In spite of the fact that I produce and distribute a
  195. number of disinfector programs, including CLEAN-UP, I always
  196. suggest deleting as a first choice.  There are many reasons for
  197. this, but the primary one is that the process of disinfecting a
  198. file always leaves an element of uncertainty in the system.
  199.           For example, the Jerusalem virus uses information in the EXE
  200. header record to determine how to infect.  Often this header record
  201. is inaccurate, causing the virus to overlay part of the EXE file,
  202. and also causing the virus to update the header record incorrectly.
  203. The virus has, in effect, destroyed part of the EXE file, and this
  204. destruction is often not noticed immediately by the user.  The
  205. corrupted area might be seldom referenced, or in a program function
  206. area that is bypassed in normal processing.  If this is the case,
  207. removal will leave a program that will at some point cause
  208. inconsistencies, data corruption, or system crashes when the erased
  209. area is referenced.  There is simply no way to recover the file
  210. because there is no way (short of using the original uninfected
  211. program) to determine what was in the file before it was
  212. overwritten.
  213.           The Jerusalem is not alone in causing these problems.  There
  214. are numerous EXE infectors and some COM infectors (405, Vienna)
  215. that cannot be successfully recovered in all cases.  What
  216. complicates the matter is that it cannot be determined in advance
  217. (in all cases) which files will disinfect correctly and which will
  218. not.  We are left then with a system that will have no more
  219. viruses, but we may have applications that are subtly corrupted.
  220. This is not good.  A program that seems to work, but may have brain
  221. damage in a seldom used subroutine, can be as troublesome as a
  222. virus.
  223.           In addition to the above problems, many viruses are
  224. continually being modified so that identification may still work,
  225. but disinfection will cause complete destruction of the file due
  226. to changed offsets and other programming issues.
  227.           To get back to my point, I would strongly suggest that
  228. infected files be overwritten in their entirety and then deleted
  229. if at all possible.  Only as a last resort, where backups or
  230. original diskettes are unavailable, should disinfection be used.
  231.  
  232. John McAfee
  233.  
  234. ------------------------------
  235.  
  236. Date:    Mon, 26 Feb 90 17:23:00 +0000
  237. From:    RMAP222@EUCLID.UCL.AC.UK (on GEC 4190 Rim-E at UCL)
  238. Subject: 1701/1704 Ver. B virus and SCAN/CLEAN Ver. 2.7 V57 (PC)
  239.  
  240. I had a following problem: when I requested a directory of my floppy
  241. disk, the machine (Toshiba 3100, DOS 3.2) read the floppy directory
  242. just once, ie, every successive request for floppy directory displayed
  243. the data from the ram, WITHOUT re-reading of actual data from the
  244. floppy. Even when chan- ging the floppy, the same thing occured, ie
  245. directory of the previous floppy was displayed. I decided to check for
  246. the virus and downloaded McAfee's SCAN/CLEAN package (Ver. 2.7 V57)
  247. from our public domain archive (Lancaster University). I ran the SCAN
  248. and it reported 1701/1704 Version B virus, with id code [170X] in
  249. about 10 *.com files (command.com was one of them). I replaced the
  250. infected command.com (booted from a clean floppy, ran SCAN, and
  251. replaced command.com), and then, since my backup's are at home, ran
  252. CLEAN, which claimed that it has repaired those remaining com files.
  253. Two of infected files (CED.COM and DOSEDIT.COM) where OK, ie following
  254. the CLEAN, I ran the CED (DOSEDIT - not at the same time), and re-ran
  255. the SCAN, and everything was OK. A number of other files
  256. (MODE.COM,MORE.COM,MOUSE.COM,LIST.COM,GREP.CO where apparently clean
  257. (CLEAN reported that it has succesfully recovered them) BUT after
  258. running them (they behaved as they should), SCAN again reported that
  259. 1701/1704 was IN THE MEMORY, but couldn't find them IN THE FILES.  Can
  260. anyone (maybe John McAfee) comment on that?
  261.  
  262. Best regards,
  263.              Nino
  264.  
  265. *******************************************************************************
  266. *JANET:       N.Margetic@uk.ac.ucl.euclid             | Mr. Nino Margetic     *
  267. *EARN/BITNET: N.Margetic%euclid.ucl.ac.uk@ukacrl      | University College    *
  268. *INTERNET: N.Margetic%euclid.ucl.ac.uk@cunyvm.cuny.edu| Dept. of Med. Physics *
  269. *Phone:       [+ 044-1  | 01] 380-9846                | 11-20 Capper Street   *
  270. *FAX:         [+ 044-1  | 01] 380-9577                | London WC1E 6AJ       *
  271. *******************************************************************************
  272.  
  273. ------------------------------
  274.  
  275. Date:    Tue, 27 Feb 90 01:13:00 -0500
  276. From:    JHSangster@DOCKMASTER.NCSC.MIL
  277. Subject: Posting scan signatures.
  278.  
  279. Possibly a useful approach to posting virus scan patterns would be for
  280. virologists to extract one or more segments of the virus code of, say,
  281. 1K bytes (that's a fairly reasonable 12 lines at 80 bytes per line).
  282. >From that posted segment or segments, the user community could
  283. arbitrarily select a substring or substrings to use for recognition of
  284. the virus.  Presumably no two users would select the same substrings, so
  285. virus writers would have to alter the entire posted segment to escape
  286. detection.  Yet the segment would not be executable (with luck!)  so
  287. posting it would not run the risk of spreading a "live" virus.
  288.  
  289. This leaves the question of how many bytes the user should include in
  290. the scan pattern to avoid false alarms.  Possibly the person posting the
  291. segment could provide guidance on this, or a general guideline could be
  292. used based on the size of the storage device to be scanned.  (Anybody
  293. know offhand the entropy per byte of virus code?)
  294.  
  295. Of course, viruses can be constructed which alter themselves at each
  296. replication, making any search with a fixed string futile, or at best,
  297. "challenging" to design.
  298.  
  299. - -John Sangster / JHSangster at dockmaster.ncsc.mil / (617) 235-8800 -
  300.  SPHINX Technologies, Inc. / Post Office Box 81287, Wellesley Hills, MA 02181
  301.  
  302. ------------------------------
  303.  
  304. Date:    27 Feb 90 16:48:56 +0000
  305. From:    bgsuvax!mckeeby@cis.ohio-state.edu (Jon Mckeeby)
  306. Subject: Ping Pong Virus (PC)
  307.  
  308. An IMB PC with a hard disk in a lab of ours was infected with the Ping Pong
  309. Virus. I know that the Ping Pong Virus is a boot infector virus so we removed
  310. it by using the DOS SYS command.  However, I have other questions about the
  311. virus.  If you have an answer please reply via the newsgroup or my mailing
  312. address: mckeeby@andy.bgsu.edu.
  313.  
  314.           1.  How does the virus spread?
  315.           2.  Are there available detection/protection programs
  316.               to safeguard against new infections.  What are they?
  317.           3.  How is the virus activated?
  318.           4.  What does the virus do besides infect the boot sector?
  319.           5.  Is the DOS SYS command the best way to remove the infection?
  320.           6.  Are there public domain programs to remove an infection
  321.               of the ping-pong / bouncing ball virus? What are they?
  322.           7.  Is the ping-pong and the bouncing ball virus the same virus?
  323.           8.  An infected user said they had the Brain virus on there disk
  324.               and before using the infected ping-ponged hard disk it was
  325.               clean.  Is there any correlation between these two viruses?
  326.               I don't think so, but I want to make sure.
  327.  
  328. Thank you very much for your time,
  329.  
  330. Jon McKeeby
  331. Graduate Assistant
  332. Microcomputer / Microcomputer Virus Support
  333. Bowling Green State University
  334.  
  335. ------------------------------
  336.  
  337. End of VIRUS-L Digest
  338. *********************
  339. Downloaded From P-80 International Information Systems 304-744-2253
  340.