home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / compress / 4543 < prev    next >
Encoding:
Internet Message Format  |  1993-01-10  |  8.4 KB

  1. Path: sparky!uunet!gatech!concert!duke!news.duke.edu!acpub.duke.edu!machteme
  2. From: machteme@acpub.duke.edu (Mark Achtemeier)
  3. Newsgroups: comp.compression
  4. Subject: pkzip204c--virus activity?
  5. Message-ID: <8476@news.duke.edu>
  6. Date: 11 Jan 93 03:34:03 GMT
  7. Sender: news@news.duke.edu
  8. Organization: Duke University; Durham, N.C.
  9. Lines: 150
  10. Nntp-Posting-Host: raphael.acpub.duke.edu
  11.  
  12. AN ANOMALOUS INCIDENT INVOLVING PKZIP 2.04C
  13.  
  14. The following is a report of an incident of virus-like activity which
  15. appeared recently on my system, possibly in connection with the use
  16. of the new version 2.04c of PKZIP.  I confess that I do not understand
  17. how all the pieces of the puzzle fit together, but I am recording the
  18. events as accurately and completely as I possibly can so that others
  19. can be on the lookout for similar phenomena.
  20.  
  21. I FTP'd the file 'pkz204c.exe' from the archive at garbo.uwasa.fi on
  22. the Internet at approx. 2:00pm est on Thursday, January 7.  The file
  23. was copied first to my storage area on the DEC terminals at Duke
  24. University, and from their FTP'd to an IBM compatible terminal on a
  25. public cluster in the Duke library.  The public terminal had been
  26. turned on when I began to use it, but its associated directories
  27. showed no files present.
  28.  
  29. On the public terminal, I ran pkz204c.exe to extract the various
  30. program and documentation files, consulted these and ran some tests
  31. comparing the performance of the new version against PKZIP 1.1 (I was
  32. delighted, I might add, with the performance of the new product!)
  33. Since I had read the discussion about the "maltese amoeba" alarms
  34. associated with this program, I ran the 'scan.exe' program in McAfee
  35. Associates' SCAN 8.6V93 package on both the original and the extracted
  36. archive files.  The program reported no viruses found.
  37.  
  38. I copied the main archive file to a floppy disk and took it to my
  39. office for installation on my office computer--a Zeos 286-12 with a 42
  40. meg IDE drive, running MSDOS 3.3.
  41.  
  42. On my own system, I copied the original archive file to a temporary
  43. directory.  Before extracting it, I executed my standard batch file
  44. (hereafter called the "standard scan") for running the McAfee scan
  45. program--I had used the /AF option some months earlier to create a
  46. file (called scanval.val, located on the c: drive) of validation codes
  47. for my program, *.sys and *.ovl files.  My standard scan batch file
  48. runs SCAN with the /CF option, checking these validation codes against
  49. the appropriate files on the disk.  This first run of the standard
  50. scan produced one alarm: for a file entitled DESKTOP.OVL associated
  51. with my PCTOOLS 5.0 package.  While it concerned me at the time, I
  52. have since discovered that this file is written to every time the
  53. PCTOOLS DESKTOP program is run in resident mode.  Since I had in fact
  54. done this after creating the file of validation codes, I have no
  55. reason to believe this file was infected at that time.
  56.  
  57. My next step was to execute the pkz014c.exe program in my c:\temp
  58. directory in order to extract the program files from the archive.  All
  59. of the files produced -AV validation codes.  Again I ran a standard
  60. scan, which continued to produce a single alarm for DESKTOP.OVL.
  61.  
  62. Satisfied that the program was virus-free, I proceeded to rename the
  63. old verisons of PKZIP and PKZIP in my utilities directory, and to copy
  64. the new versions of these programs into it.  I then executed a
  65. standard batch file which calls PKZIP three times in order to back up
  66. three different directory trees onto a floppy disk.
  67.  
  68. The job ran successfully, and again, I was delighted with the speed of
  69. the new version of PKZIP.
  70.  
  71. Wanting to be on the safe side, I then decided to do a final run of
  72. the standard scan.  This scan was done immediately after the PKZIP
  73. batch job, with no other programs run in the interim. This time, to my
  74. horror, the program produced alarms for my MSDOS.SYS file, along with
  75. every file on my disk containing and extension of '.OVL'.  No other
  76. files were affected.  The overlay files, approximately twelve in all,
  77. resided in three separate directories on my c: drive.  The alarms
  78. simply said: "File has been modified, a virus infection may have
  79. occurred".  No indication of the identity of the virus was given, nor
  80. did the program's memory scans pick up anything.  I had to leave my
  81. system for the day at this point, since the library where my office is
  82. located was closing.
  83.  
  84. That evening I spent some time plotting strategy for ridding my system
  85. of what I assumed was an infection.  I determined that I would prepare
  86. a write-protected, bootable floppy disk on my home system, containing
  87. uninfected copies of the overlay and MSDOS.SYS files, which I would
  88. use to replace the damaged files.
  89.  
  90. The next morning, I executed a boot from power-off of the write-
  91. protected floppy disk.  I had set up the floppy to install a new
  92. versions of the PCTOOLS SHELL utility to a temporary directory on the
  93. c: drive.  I then used this utility to delete the MSDOS.SYS and IO.SYS
  94. files (which I replace using the DOS 'sys' command) and also to
  95. overwrite all of the .OVL files with the clean versions.
  96.  
  97. Having finished this procedure, I powered off the system and did a
  98. reboot from the c: drive.  I immediately ran the standard scan, and
  99. was puzzled to find that while the number of alarms had decreased, a
  100. number were still reported.  The MSDOS.SYS file still registered as
  101. corrupt, along with three or four of the .OVL files.  After puzzling
  102. over this awhile, I tried repeating the procedure of powering down the
  103. system, booting from the floppy, deleting the old files and replacing
  104. them with with the uninfected versions.  A subsequent run of the
  105. standard scan continued to produce alarms.
  106.  
  107. {On two occasions during all this--I am fuzzy on just when they were--
  108. I also noted that an attempt to run a program contained on my utility
  109. floppy produced an error message of "Write protect error: unable to
  110. write to floppy disk" or something to that effect.  This struck me as
  111. highly unusual, since nothing in the command or program involved
  112. should have called for a write to the diskette.}
  113.  
  114. Thinking that perhaps the files from my home system were infected, I
  115. used the temporary version of PCTOOLS on the c: drive to run a
  116. comparison between the supposedly uninfected files on the floppy disk
  117. and the which were still producing alarms on the c: drive.  The
  118. comparison, to my bewilderment, showed that the MSDOS.SYS and overlay
  119. files in question were, in fact, different from their source files on
  120. the floppy which I had copied onto the c: drive a few moments earlier.
  121.  
  122. In desperation I did a final run of the standard scan.  This time it
  123. produced *more* alarms--still not for all the overlay files on the
  124. disk, but for more than had been reported in the run immediately
  125. preceeding it.
  126. At this point I panicked and decided that drastic action was called
  127. for.  I used PCTOOLS to make copies of the infected MSDOS.SYS and
  128. *.OVL file on a clean floppy for future reference.  Alas, I did not
  129. think to examine them closely at the time.  I then did a power-off
  130. boot from my write-protected, utility floppy, and used FDISK to delete
  131. all of my drive partitions.  I proceeded to set up the disk from
  132. scratch, installing a new operating system (DRDOS 6) which I had been
  133. meaning to do for some time anyway, and restoring my program and data
  134. files from a set of backups which (fortunately) I had done only a few
  135. days before.  I did scans (with new validation files) throughout the
  136. process and have not encountered any virus alarms since.
  137.  
  138. A puzzling final note:  I have since had the opportunity to examine
  139. the copies of the infected files which I had copied to floppy disk.
  140. Compares run against uninfected versions of the same files on my home
  141. system reveals no difference between the files--this in spite of the
  142. fact that the differences were clearly evident when they resided on
  143. the c: drive.
  144.  
  145. If this is a case of virus infestation, there are a lot of aspects of
  146. it I don't understand--like how a virus could turn up active in a
  147. system booted from a clean, write-protected floppy, for starters.  The
  148. temptation for me has been to leave out various details from the
  149. account in order to make the emergent picture a clearer one.  I have
  150. decided, though, that everyone's best interest will be served by as
  151. complete and accurate an account as possible, and this is what I have
  152. struggled to provide.
  153.  
  154. I have available for the asking:  copies of the now mysteriously
  155. intact files which were copied from the infected c: drive onto floppy.
  156. Copies of the original pkz204c.exe file which started this whole
  157. incident (maybe!) to begin with.
  158.  
  159. P. Mark Achtemeier
  160. Duke University
  161. machteme@acpub.duke.edu
  162.