home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.159 < prev    next >
Text File  |  1995-01-03  |  9KB  |  195 lines
  1. VIRUS-L Digest   Tuesday, 25 Jul 1989    Volume 2 : Issue 159
  2.  
  3. Today's Topics:
  4.  
  5. query re: archive access
  6. re: the CHRISTMA EXEC on BITNET and VNET (IBM VM/CMS)
  7. Missouri virus news? (PC)
  8. Wanted: Beta Testers for Flu_Shot+ (PC)
  9. RE: the CHRISTMA EXEC on BITNET and VNET (IBM VM/CMS)
  10. update to F-PROT.ARC (PC)
  11.  
  12. ---------------------------------------------------------------------------
  13.  
  14. Date:    Mon, 24 Jul 89 11:27:43 -0400
  15. From:    "M.S.Kolansky" <TERE%ERENJ.BITNET@IBM1.CC.Lehigh.Edu>
  16. Subject: query re: archive access
  17.  
  18. Can someone tell me how to get at the LISTSERV virus archives.
  19.  
  20. [Ed. Send mail to LISTSERV@LEHIIBM1.BITNET (same as
  21. LISTSERV@IBM1.CC.LEHIGH.EDU - for Internet users) containing one or
  22. more of the following commands:
  23.  
  24. HELP                      - to get help
  25. INDEX VIRUS-L             - to get a list of available files
  26. GET filename filetype     - to retrieve a particular file (via e-mail)
  27.  
  28. ]
  29.  
  30. ------------------------------
  31.  
  32. Date:    24 Jul 89 00:00:00 +0000
  33. From:    David M. Chess <CHESS@YKTVMV.BITNET>
  34. Subject: re: the CHRISTMA EXEC on BITNET and VNET (IBM VM/CMS)
  35.  
  36. While I was lucky enough to be on vacation when CHRISTMA hit
  37. VNET, my impression is that (press to the contrary), VNET
  38. handled it about like BITNET did: a few nodes shut down or
  39. cold started, but most just installed and ran some filters
  40. on RSCS and local spool.   Lots of human and CPU time and net
  41. bandwidth wasted, but not a system-wide shutdown.  This is
  42. just an unofficial impression, of course!
  43.  
  44. As far as I know, it's no harder to get a file from BITNET to
  45. VNET now than it was before CHRISTMA; the person you want to
  46. talk to on the VNET side has to be authorized with the gateway.
  47. Exactly how an IBMer gets authorized for BITNET access varies
  48. with site/division/etc.   I'm authorized, for instance, and I
  49. can be sent mail from BITNET just by sending in the normal way
  50. to CHESS at YKTVMV (let's not all try this just to be sure it
  51. works, of course!  Hehe).
  52.  
  53. DC
  54. IBM T. J. Watson Research Center
  55.  
  56. ------------------------------
  57.  
  58. Date:    Mon, 24 Jul 89 15:07:42 -0400
  59. From:    "Dennis P. Moynihan" <DMOYNIHA@WAYNEST1.BITNET>
  60. Subject: Missouri virus news? (PC)
  61.  
  62. Way back in April the following was reported to this list:
  63.  
  64. >Date:    Thu, 27-Apr-89 13:57:27 PDT
  65. >From:    portal!cup.portal.com!Alan_J_Roberts@Sun.COM
  66. >Subject: Missouri Virus (PC)
  67. >
  68. >The Homebase group has logged over a dozen occurrences of this virus
  69. >but we have never successfully sampled it.  The latest occurrence was
  70. >notable enough to pass on to Virus-L so that we might get some
  71. >assistance.  The occurance was at the National Security
  72. >Administration.  The virus came into their shop on a disk shipped with
  73. >the book - "DOS Power Tools", published by Bantam.  This was the third
  74. >report of the virus entering an installation on this book.  The virus
  75. >completely disables writing to the hard disk, but it does allow normal
  76. >reading of data already stored.  Every site that has been hit has
  77. >destroyed or lost the original source disk, and the target disk.  The
  78. >NSA is no exception.  Robert Dimsdale of the NSA in Fort Meade
  79. >originally reported the virus to the CVIA and he cut the floppy into 8
  80. >sections prior to calling.  He then disrarded the standard CVIA advice
  81. >and low level formatted the hard disk.  Anyone with any additional
  82. >information about this virus is invited to share that information with
  83. >what we already know by contacting the HomeBase board.  We know that
  84. >Missouri is a virus and not a Trojan because we have documented four
  85. >occurances of its replication.  Please do not contact Mr. Dimsdale
  86. >directly.  Serious inquiries should be addressed through Jim Corwell
  87. >on Homebase.  He will pass on your name to the NSA and they will
  88. >reply.
  89. >   ....
  90.  
  91. This just became a bit of a hot topic here today.  We noted the report
  92. in our newsletter and have been receiving calls about it.  Most have been
  93. from users who have "Dos power tools" and want to know if their machine
  94. will roll over any time soon.  One, interestingly, was from Bantam.  They
  95. wanted to know where we got this from.
  96.  
  97. Anyway, have there been any more reports regarding this virus?  I got the
  98. impression from the above that if a copy of "Dos power tools" had the
  99. virus people found out quick.  Any other news in general on this?
  100.  
  101. - --------------------------------------
  102. Dennis Moynihan    (DMOYNIHA@WAYNEST1)
  103. Computing and Information Technology
  104. Wayne State University
  105. Detroit, MI
  106.  
  107. ------------------------------
  108.  
  109. Date:    Mon, 24 Jul 00 19:89:34 +0000
  110. From:    utoday!greenber@uunet.uu.net
  111. Subject: Wanted: Beta Testers for Flu_Shot+ (PC)
  112.  
  113. I'm all set to release a new version of FLU_SHOT+ and need some people
  114. as beta testers (all my current beta testers opted to take the summer
  115. off, those lucky dogs!).
  116.  
  117. Requirements: MS-DOS 2.x - 4.x.  In particular, I'm looking for 4.x
  118. people (there were some problems with the last release and 4.x)
  119.  
  120. Send *me* E-mail, not the list.  Many thanks.
  121.  
  122. Ross M. Greenberg
  123. Author, FLU_SHOT+
  124.  
  125. ------------------------------
  126.  
  127. Date:    Mon, 24 Jul 89 16:14:00 -0700
  128. From:    "Hervey Allen, U of O Comp. Ctr., (503) 686-4394" <HALLEN@oregon.bitne
  129.           t>
  130. Subject: RE: the CHRISTMA EXEC on BITNET and VNET (IBM VM/CMS)
  131.  
  132. I have been reading the discussions on VM/CMS as pertaining to viruses and
  133. security with some interest.  I was the Senior Consultant/Programmer at a
  134. small college for a system running VM/CMS when the CHRISTMA EXEC program
  135. was making its rounds.
  136.  
  137. There were two of us who had complete control over the machine we were work-
  138. ing on (a 4341-2 w/1500 accounts) which made it extremely easy to spot and
  139. eradicate the CHRISTMA EXEC.  We routinely checked the number of Reader (mail)
  140. files on our machine.  We noticed an increase in files over the span of a few
  141. hours that was unusual so we checked our RSCS spool to see if anything unusual
  142. was happening and spotted the CHRISTMA EXEC file showing up repeatedly.  We
  143. then took a look at the CHRISTMA EXEC (which we had both received) and
  144. realized what it was doing.  At this point we wrote a few lines of code to
  145. search for all occurrences of the CHRISTMA EXEC on the system (in Reader or
  146. on disk) and to delete any that were found.  We warned our users not to run
  147. the CHRISTMA EXEC (in case we missed any) and then we periodically checked
  148. for the EXEC over the next few days.  We did not think of putting the check
  149. directly into RSCS, which is a better idea.
  150.  
  151. The reason I bothered to write this was to make note of the possibility that
  152. those places where people dealt directly with their machines and the operating
  153. systems seemed to catch the CHRISTMA EXEC almost immediately, whereas on the
  154. IBM VNET many of the machines ran systems such as PROFS that separate the
  155. users from the operating system and most of the machines were maintained by
  156. a larger number of people who had less direct control over their environ-
  157. ments.  I'm not advocating either system over the other, but, to us, it was
  158. interesting how trivial a problem the CHRISTMA EXEC was to deal with.  On
  159. IBM's VNET, however, the offending program was not noticed until network
  160. traffic had become so high, and system spool resources were becoming full
  161. enough (I assume) that they were forced to shut the network down.
  162.  
  163. This begs the question as to whether or not systems that are designed to be
  164. user friendly and administrations that are set up to keep access to data
  165. restricted are more susceptible to viruses/worms/trojan horses.  I don't
  166. expect to answer this question, but it does seem to be a re-occurring theme
  167. when dealing with viruses.
  168.  
  169. Hervey Allen  <<Bitnet:   HALLEN@OREGON.Bitnet>>
  170.               <<Internet: HALLEN@oregon.uoregon.edu>>
  171.  
  172. Student Programmer/Virus Consultant
  173. University of Oregon Academic Computer Services
  174.  
  175. | Disclaimer:  The opinions expressed here are my own and in no way reflect |
  176. |              the opinions of the University of Oregon.                    |
  177.  
  178. ------------------------------
  179.  
  180. Date:    Tue, 25 Jul 89 05:39:26 -0500
  181. From:    jwright@atanasoff.cs.iastate.edu (Jim Wright)
  182. Subject: update to F-PROT.ARC (PC)
  183.  
  184. I'm sending out an update to the f-prot package.  Apparently there is
  185. some problem with one of the programs and some TSR programs.  The
  186. F-LOCK.EXE program is being replaced in this update.
  187.  
  188. Jim
  189.  
  190. ------------------------------
  191.  
  192. End of VIRUS-L Digest
  193. *********************
  194. Downloaded From P-80 International Information Systems 304-744-2253
  195.