home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.185 < prev    next >
Text File  |  1995-01-03  |  13KB  |  308 lines
  1. VIRUS-L Digest   Tuesday,  5 Sep 1989    Volume 2 : Issue 185
  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. Anti-Virus/Virus Listing
  17. Re: Is this a virus? (PC)
  18. RE: capturing viruses (Mac)
  19. Columbus Day Virus and Lehigh (PC)
  20. Re: Is this a virus? (PC)
  21. Virus or no? Help please (PC)
  22. Re: is this a virus? (PC)
  23. Kim's question concerning FATs (PC)
  24. removing a floppy then Retry (PC)
  25. Columbus Day "virus" (PC)
  26. Re: Virus Naming
  27. Appleshare and viruses ?
  28.  
  29. ---------------------------------------------------------------------------
  30.  
  31. Date:    Fri, 01 Sep 89 06:28:54 -0700
  32. From:    portal!cup.portal.com!Chuck_SirVAX_Staatse@apple.com
  33. Subject: Anti-Virus/Virus Listing
  34.  
  35. I teach a class on hard disk management. Naturaly I cover virues, but
  36. do not have a list of virus names and what programs are currently
  37. available to combat these viruses. Coulde someone please post a list
  38. of this information. Could you also include some information about
  39. the CV group who are working to combat these viruses.
  40.                               Thanks, Chuck
  41.  
  42. ------------------------------
  43.  
  44. Date:    01 Sep 89 00:00:00 +0000
  45. From:    David M. Chess <CHESS@YKTVMV.BITNET>
  46. Subject: Re: Is this a virus? (PC)
  47.  
  48. >                                        ...if I answer "r" to the
  49. > massage and puting a non-protected diskette, then the FAT and
  50. > DIRECTORY of the protected diskette is transfered to the second non
  51. > protected diskette(and the files that I copied to).
  52.  
  53. DOS has always done this, I think.  I believe some versions of the
  54. documentation Strongly Warn against switching diskettes during the
  55. "Abort, Retry..." message.  I realize that may not be much
  56. consolation!  But it's not a virus, at least...
  57.  
  58. DC
  59.  
  60. ------------------------------
  61.  
  62. Date:    Fri, 01 Sep 89 10:19:00 -0400
  63. From:    "Alex Z." <ACSAZ@SEMASSU.BITNET>
  64. Subject: RE: capturing viruses (Mac)
  65.  
  66. Well, with a virus (take scores for example), you could identify the
  67. infected files and then view them with a utility like Fedit+. I think
  68. that would be a better way to view the code than Resedit.
  69.  
  70.                                    Alex Z... . .  .
  71.  
  72.  
  73. ------------------------------
  74.  
  75. Date:    Fri, 01 Sep 89 08:11:05 -0700
  76. From:    portal!cup.portal.com!Alan_J_Roberts@Sun.COM
  77. Subject: Columbus Day Virus and Lehigh (PC)
  78.  
  79.         Ken van Wyk asks about the Columbus day Virus.  It's the same as
  80. the DataCrime virus versions one and two (not to be confused with the
  81. DataCRime II).  Columbus day is October 12.  The Datacrime versions 1 and 2
  82. activate on October 12.  I would discourage the use of "Columbus Day Virus"
  83. as a name, since DatCrime has been an accepted name for quite some time.
  84.         Also, the Lehigh original virus has been sporadically reported at
  85. dozens of installations outside of the university for over a year.  It is
  86. not a particulary successful replicator -- probably because of the extremely
  87. short activation fuse - and it is difficult to detect and report because
  88. there are few symptoms prior to activation.  Buit there should certainly be
  89. no surprise that it's in the public domain.  In John McAfee's report to the
  90. CVIA on epidemiology he writes - "The belief that viruses can be contained
  91. by early counter-action is belied by the Lehigh University experience.  I
  92. have spoken to a number of individuals at the University who belived that
  93. the virus had somehow been contained because "no copies of the virus were
  94. distributed to outside organizations".  This assumed, of course, that the
  95. original virus writer gave up after being foiled at Lehigh and did not insert
  96. the virus at any other location, and that all copies of the virus at Lehigh
  97. had indeed been accounted for.  The first issue rests solely in the hands of
  98. the perpetrator and is beyond any containment controls.  The second issue
  99. relies on an error-free containment process - allowing no possibility for
  100. overlooking, losing or mistaking an infected diskette.  In any case, the
  101. Lehigh virus was by no means contained.  I received a copy, as did virtually
  102. every virus researcher, in mid-1988, and infection reports issued throughout
  103. the year from universities, corporations and individual computer users."
  104.         I think John said it better than I could, but my sentiments exactly.
  105. Alan
  106.  
  107. ------------------------------
  108.  
  109. Date:    Fri, 01 Sep 00 11:51:00 -0400
  110. From:    Bob Babcock <PEPRBV%CFAAMP.BITNET@IBM1.CC.Lehigh.Edu>
  111. Subject: Re: Is this a virus? (PC)
  112.  
  113. >When I copy some
  114. >files to a floppy but I misput a write protected diskette, I find the
  115. >error massage "retry, ...". At this time, if I answer "r" to the
  116. >massage and puting a non-protected diskette, then the FAT and
  117. >DIRECTORY of the protected diskette is transfered to the second non
  118. >protected diskette(and the files that I copied to). Is this a DOS's
  119. >bug or a virus?
  120.  
  121. This is a known behavior of MS-DOS.  The directory and FAT have
  122. already been read before the write protect error is sensed, and
  123. when you say retry, DOS doesn't know that you have changed disks,
  124. so it doesn't reread the directory info.
  125.  
  126.  
  127. ------------------------------
  128.  
  129. Date:    Fri, 01 Sep 89 12:31:00 -0400
  130. From:    <ACSAZ@SEMASSU.BITNET>
  131. Subject: Virus or no? Help please (PC)
  132.  
  133.  
  134.     At our university a student came in and described a problem with
  135. his AT compatible and wondered if it was a virus.  The symptoms
  136. follow:
  137.  
  138.     1. lots of garbage on screen.
  139.     2. repeat of dos prompt across the screen.
  140.     3. I view all my files with .sys and found word BUG .
  141.     4  I could't do any work at the time, but following day all
  142.         seemed okay.
  143.  
  144. Any of you IBM specialists have any ideas on this one?
  145.  
  146.                                    Alex Z... . .  .
  147.                                    Library Mac Software Chief
  148.                                    SMU
  149.  
  150. ------------------------------
  151.  
  152. Date:    Fri, 01 Sep 89 16:55:59 -0500
  153. From:    Joe Simpson <JS05STAF@MIAMIU.BITNET>
  154. Subject: Re: is this a virus? (PC)
  155.  
  156. In response to the question about the FAT from a locked disk being
  157. written to another disk this is a feature of MS-DOS, not a virus.
  158.  
  159. Another chilling scenario conserns running an application such as a
  160. word processor, opening a document, exchangeing data diskettes, and
  161. saving a "backup" of the file.  This often hoses the "backup" disk and
  162. sometines affects the origional file.
  163.  
  164. ------------------------------
  165.  
  166. Date:    01 Sep 89 15:41:00 -0400
  167. From:    "Damon Kelley; (RJE)" <damon@umbc2.umbc.edu>
  168. Subject: Kim's question concerning FATs (PC)
  169.  
  170. In response to Kim:
  171.     I'm no expert at MS-DOS or software-stuff, but I've been poking
  172. around in my computer's memory long enough to believe that what you
  173. are describing may be normal with MS-DOS.  Often I see that within
  174. memory, data stays in its assigned spot until something moves or
  175. writes over it.  I notice this effect with a certain software
  176. word-processing/graphing/spreadsheet package I have.  Sometimes when I
  177. am retreiving data with my package, I place a data disk first before
  178. putting in the main program disk. The program needs to do something
  179. with the disk with the main program first, so the package asks for the
  180. main program disk.  Whe the directory pops up for the main program
  181. disk, it shows a conglomeration of the files on the curent disk PLUS
  182. the files that were on the removed data disk and some random garbage.
  183. Nothing grave has happened to my files with this package (It came with
  184. my computer.  It wasn't PD/Shareware, either.), so I feel that this
  185. may be either a DOS bug (not writing over completely the FAT) or
  186. something normal.  Of course, I've never really had an opportunity to
  187. look at the directory track on any disks, so I can't confirm that this
  188. is absolutely true.  I can find out.  Has anyone out there found mixed
  189. FATs affecting the performance of their disks?
  190.  
  191. jnet%"damon@umbc"
  192. damon@umbc.bitnet
  193. damon@umbc2.umbc.edu
  194.  
  195. "Would anyone dare let me represent their views?  I think not!!!"
  196.  
  197.  
  198. ------------------------------
  199.  
  200. Date:    Sat, 02 Sep 89 00:00:00 +0000
  201. From:    "Prof Arthur I. Larky" <AIL0@LEHIGH.BITNET>
  202. Subject: removing a floppy then Retry (PC)
  203.  
  204. > I 'm a college student studying physics.  Now I have discovered a
  205. > suspicious thing about MS-DOS's behavior in my sense. When I copy some
  206. > files to a floppy but I misput a write protected diskette, I find the
  207. > error massage "retry, ...". At this time, if I answer "r" to the
  208. > massage and puting a non-protected diskette, then the FAT and
  209. > DIRECTORY of the protected diskette is transfered to the second non
  210. > protected diskette(and the files that I copied to). Is this a DOS's
  211. > bug or a virus?
  212.  
  213.    It's a "feature" of MSDOS - when you attempt to write on a floppy,
  214. MSDOS reads the FAT and  Directory and re-writes it when you are done.
  215. If you swap floppies, you get the old information on the new disk.
  216.  
  217.   The rule is: NEVER NEVER replace a floppy with another in the middle
  218. of a write or a write protect error.  Pick the Abort option, not the
  219. Retry option; then start the process all over.
  220.  
  221.   Anyway, it's not a virus, it's just Bill Gates getting even with the
  222. world for making him a billionaire.
  223.  
  224. Art Larky
  225. CSEE Dept
  226. Lehigh University
  227.  
  228. ------------------------------
  229.  
  230. Date:    Sat, 02 Sep 89 16:05:53 -0400
  231. From:    dmg@lid.mitre.org (David Gursky)
  232. Subject: Columbus Day "virus" (PC)
  233.  
  234. Yes, I have heard of the "Columbus Day 'virus'".  What I have heard is
  235. a pronouncement from a certain Dr. S. that this thing exists and on
  236. Friday, October 13th, this bugger is going to strike and start causing
  237. problems.
  238.  
  239. IMO, this sounds suspiciously like the Jerusalem/Hebrew University
  240. virus, *at this point*.
  241.  
  242. Emily Lonsford, a fellow MITRE-ite and contributor here, has meet Dr.
  243. S., and was less then impressed with him and his techniques.
  244.  
  245. Of course, none of this means that this virus does not exist as a
  246. seperate strain from existing viruses.  Barring independant
  247. confirmation of this virus, my opinion is that no extraordinary action
  248. is needed.
  249.  
  250. [Ed. Thanks for the info - in fact, I received a number of replies
  251. about the Columbus Day virus.  Most replies indicated that it was the
  252. DataCrime virus.  Thanks to all those who replied!]
  253.  
  254. ------------------------------
  255.  
  256. Date:    03 Sep 89 18:58:31 +0000
  257. From:    dav@eleazar.dartmouth.edu (William David Haas)
  258. Subject: Re: Virus Naming
  259.  
  260.  
  261. In article <0001.8909011255.AA07043@ge.sei.cmu.edu> ttidca.TTI.COM!hollombe%sdc
  262. svax@ucsd.edu (The Polymath) writes:
  263. <EICHTER@Venus.YCC.Yale.Edu (Jerry Leichter) writes:
  264. <}... When the discoverer doesn't choose a name, the disease
  265. <}often gets named after him (Wernickie's Aphasia).
  266. <
  267. <I think this is the way to go for simple psychological reasons.
  268. <Naming a virus for its discoverer is a strong discouragement to the
  269. <virus writers.  Imagine the frustration of writing what you think is a
  270. <really nifty virus, only to have someone else's name associated with
  271. <it.  Not much incentive there.
  272. <
  273. <There's more than one way to fight this war.
  274.  
  275. And then you will have virus writers 'discovering' their own work to
  276. their name on it.
  277.  
  278. ------------------------------
  279.  
  280. Date:    04 Sep 89 01:18:53 +0000
  281. From:    gilbertd@silver.bacs.indiana.edu (Don Gilbert)
  282. Subject: Appleshare and viruses ?
  283.  
  284. What are the conditions under which current Mac viruses can
  285. infect files on Appleshare volumes?
  286.  
  287.   a.  All ashare files are susceptible if volume is mounted
  288.       to an infected Mac.
  289.   b.  Only files in write- AND read-enabled folders are
  290.       susceptible.
  291.   c.  Files in write-enabled folders are susceptible (read
  292.       access doesn't matter).
  293.   d.  Files in read-enabled folders are susceptible (write
  294.       access doesn't matter).
  295.   e.  Gee, the students are back in town, better lock up your
  296.       file servers.
  297.  
  298. Don Gilbert                                  biocomputing office
  299. gilbertd@iubacs.bitnet            gilbertd@gold.bacs.indiana.edu
  300.   biology dept.    indiana univ.     bloomington, in 47405 usa
  301.  
  302.  
  303. ------------------------------
  304.  
  305. End of VIRUS-L Digest
  306. *********************
  307. Downloaded From P-80 International Information Systems 304-744-2253
  308.