home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.102 < prev    next >
Text File  |  1995-01-03  |  7KB  |  144 lines
  1. VIRUS-L Digest              Friday, 28 Apr 1989        Volume 2 : Issue 102
  2.  
  3. Today's Topics:
  4. Missouri Virus (PC)
  5. Net Hormones Paper by David S. Stodolsky
  6. Trojan REXX EXECs (VM/CMS)
  7. Problem in BASIC virus related? (PC)
  8.  
  9. ---------------------------------------------------------------------------
  10.  
  11. Date:    Thu, 27-Apr-89 13:57:27 PDT
  12. From:    portal!cup.portal.com!Alan_J_Roberts@Sun.COM
  13. Subject: Missouri Virus (PC)
  14.  
  15. The Homebase group has logged over a dozen occurrences of this virus
  16. but we have never successfully sampled it.  The latest occurrence was
  17. notable enough to pass on to Virus-L so that we might get some
  18. assistance.  The occurance was at the National Security
  19. Administration.  The virus came into their shop on a disk shipped with
  20. the book - "DOS Power Tools", published by Bantam.  This was the third
  21. report of the virus entering an installation on this book.  The virus
  22. completely disables writing to the hard disk, but it does allow normal
  23. reading of data already stored.  Every site that has been hit has
  24. destroyed or lost the original source disk, and the target disk.  The
  25. NSA is no exception.  Robert Dimsdale of the NSA in Fort Meade
  26. originally reported the virus to the CVIA and he cut the floppy into 8
  27. sections prior to calling.  He then disrarded the standard CVIA advice
  28. and low level formatted the hard disk.  Anyone with any additional
  29. information about this virus is invited to share that information with
  30. what we already know by contacting the HomeBase board.  We know that
  31. Missouri is a virus and not a Trojan because we have documented four
  32. occurances of its replication.  Please do not contact Mr. Dimsdale
  33. directly.  Serious inquiries should be addressed through Jim Corwell
  34. on Homebase.  He will pass on your name to the NSA and they will
  35. reply.
  36.  
  37. Another report that came in on the same day, co-incidentally, involved
  38. another book called - "Using Application Software" from Random House.
  39. It was reported at Florida International University, contact name -
  40. Mitchel Zidel.  We have not yet followed this one up.  If any of you
  41. folks would like to join the Sleuth Team, contact Jim and sign up for
  42. this one.  He has the phone number and specifics.
  43.  
  44. P.S. A number of HomeBase users would like to communicate with
  45. Virus-L.  They are all, however, local BBS users and none (with one or
  46. two exceptions) have access to Usenet or Bitnet.  How can I go about
  47. posting their mail on Virus-L?
  48.  
  49. ------------------------------
  50.  
  51. Date:    Fri, 28 Apr 89 11:59:11 MDT
  52. From:    Chris McDonald <cmcdonal@wsmr-emh10.army.mil>
  53. Subject: Net Hormones Paper by David S. Stodolsky
  54.  
  55. I read with interest the subject paper which resulted in some questions.
  56.  
  57. First, if contact tracing is technically possible among hosts and
  58. networks, is the proposed "theory of operation" described in paragraph
  59. 4 of the paper really practical?  Dr. Stodolsky proposes that: "In the
  60. event that a system is identified as infected, the transaction codes
  61. which could represent transactions during which the agent was
  62. transmitted are broadcast to all other computers."  The words "which
  63. could represent transactions" suggests that an attack which used a
  64. delay mechanism or "time bomb" approach would make it extremely
  65. difficult to identify suspect transactions in a timely manner.  It
  66. might also suggest that the historical record of transactions would of
  67. necessity be inordinately large and for practical reasons might be
  68. difficult to implement.
  69.  
  70. Second, even though Dr. Stodolsky stresses that the contact tracing
  71. operation would alert a system to the "possibility" of an agent's
  72. presence, does this represent a significant improvement over other
  73. more conventional means to broadcast alerts of a potential problem, as
  74. is now done over the Internet?  For example, if I were running a BSD
  75. version of UNIX last November, the tcp-ip broadcast alert--assuming
  76. the gateways were still up and functioning--might have been adequate
  77. to respond to the Internet Worm.  If "contact tracing" had been
  78. available, however, would not non-BSD UNIX systems have received
  79. "alerts" which would have caused unnecessary concern?
  80.  
  81. Third, if the alert through contact tracing is to "restrict further
  82. transmission of the agent," is not cutting off communications among
  83. hosts on a network the only practical solution pending further
  84. investigation?  If so, do we not have the mecahnism to do that now,
  85. however imperfectly?
  86.  
  87. Chris McDonald
  88. White Sands Missile Range
  89.  
  90. ------------------------------
  91.  
  92. Date:    Fri, 28 Apr 89 15:42:58 EDT
  93. From:    "Gregory E. Gilbert" <C0195@UNIVSCVM.BITNET>
  94. Subject: Trojan REXX EXECs (VM/CMS)
  95.  
  96. I have noticed that a number of "mischievious" (? spelling) EXECs
  97. (VM/CMS) capture information in the NAMES file on one's disk and
  98. forward themselves to users listed in one's names file.  Is there any
  99. way to prevent this (forwarding) from occuring should, by chance and
  100. unknowingly, an EXEC be invoked?
  101.  
  102. [Ed. How about renaming (or encrypting) your names file all the time,
  103. except when you're in MAIL or MAILBOOK?  Not elegant, perhaps, but
  104. probably effective.]
  105.  
  106. ------------------------------
  107.  
  108. Date:    Fri, 28 Apr 89 15:52:35 EST
  109. From:    Mignon Erixon-Stanford <IRMSS907@SIVM.BITNET>
  110. Subject: Problem in BASIC virus related? (PC)
  111.  
  112.       One of our guys wrote a BASIC file which reads one ASCII
  113. file and writes it out to another ASCII file (just a different
  114. arrangement of the data.) The interpreter & compiled versions
  115. worked perfectly at our main site (on PS/2 Model 60).
  116.  
  117.       Same guy went to outlying research facility.  The interpreter
  118. version ran fine (on AT machine).  Guy did a DIR B: of disk 1 which
  119. contained data files.  Then Guy did DIR B: of disk 2 (which contained
  120. a basic compiler).  The FAT of disk 2 got overwritten by ASCII
  121. characters of file info about disk 1.
  122.  
  123.       We could not recreate the error on the AT nor back at our
  124. main site.  This sounded like a problem with the buffers,
  125. so i Suggested they:
  126.  
  127.       increase # files & buffers in CONFIG.SYS;
  128.       boot from back-up copy of original DOS disk & do a SYS C: ;
  129.       set file attribute on COMMAND.COM to READ ONLY;
  130.       check for viruses;
  131.       have tighter controls on what software is put on machine.
  132.  
  133. But if any of you folks out there have other suggestions, please write me.
  134. Thanks.
  135.  
  136.                       Mignon Erixon-Stanford, Smithsonian Institution
  137.                       otherwise known as IRMSS907 @ SIVM
  138.  
  139. ------------------------------
  140.  
  141. End of VIRUS-L Digest
  142. *********************
  143. Downloaded From P-80 International Information Systems 304-744-2253
  144.