home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.83 < prev    next >
Text File  |  1995-01-03  |  6KB  |  142 lines
  1.  
  2. VIRUS-L Digest              Friday, 7 Apr 1989          Volume 2 : Issue 83
  3.  
  4. Today's Topics:
  5. More thoughts on potential nasy Mac Boot Block virus (Mac)
  6. Error in Thinking (PC)
  7. re: A New Virus Perhaps (PC)
  8. Zip "virus" isn't a virus (PC)
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date: Thu, 06 Apr 89 19:20:23 EST
  13. From: dmg@mwunix.mitre.org
  14. Subject: More thoughts on potential nasy Mac Boot Block virus (Mac)
  15.  
  16. In Virus-L, Joe McMahon (XRJDM@SCFVM.GSFC.NASA.GOV) wrote...
  17.  
  18. >Well, from looking in general at the history of Mac viruses so far
  19. >they've followed Apple's implementation guidelines remarkably well :-).
  20.  
  21. When in Cupertino, do like Steve Jobs does... <Big Grin>
  22.  
  23. >The viruses all used standard Mac facilities in a slightly nonstandard
  24. >way to reproduce and spread; the ANTI virus (the most recent one) is
  25. >the first to do anything different, and that one *still* doesn't
  26. >really do anything exceptional.
  27.  
  28. >The boot blocks are a different matter. As I recall, part of the
  29. >"bootstrap" code is in the ROM (the blinking-question-mark disk) and
  30. >part on the disk itself. I also don't believe that there are calls
  31. >level and mess with it. Not that this couldn't be done, it's just much
  32. >harder that diddling another virus with ResEdit and releasing it.
  33.  
  34. No question about it.  A Mac Boot Block virus (henceforth I'm going to
  35. call this thing "the Sad Mac virus") would be sophisticated IMHO, but
  36. I'm not 100% certain.  Correct me if I'm wrong, but does not the Mac
  37. boot blocks contain the name of the file the ROM bootstrap should load
  38. into RAM?  If this is the case, the Sad Mac virus would only need to
  39. change this name to some other file, and voila', its infiltrated the
  40. machine.  Yes, I'm grossly simplyfing things, but I've long since
  41. retired from hacking.
  42.  
  43. On a related subject, suppose I went to the U.S. Copyright office, and
  44. copyrighted the idea for the Sad Mac virus.  Does this mean that if
  45. someone actually went and implemented it, they are prosecutable not
  46. only under the Computer Infiltration Act (or whatever it is called),
  47. but the Copyright Act?  Have I come up with a concept that can be
  48. copyrighted?  I doubt it is patentable.
  49.  
  50. Disclaimer:  Good evening.  I'm David Gursky, and you're not.
  51.  
  52. David M. Gursky
  53. Member of the Technical Staff, W-143
  54. Special Projects Department
  55. The MITRE Corporation
  56.  
  57. ------------------------------
  58.  
  59. Date:         Fri, 07 Apr 89 11:24:53 MEZ
  60. From:         Thomas Friedrich (Ghost) <UZR50F@DBNRHRZ1.BITNET>
  61. Subject:      Error in Thinking (PC)
  62.  
  63.      Hi, there
  64.  
  65. i told of a new possible virus, but it was a mistake by me and other
  66. people who haven't enough knowledge to check up. A system programmer
  67. here told us today, that the string "Packed file is corrupt" is a
  68. regular error code by the DOS program EXEPACK. It optimizes the memory
  69. holding by a program and builds checksums. If starting such packed
  70. program the machine loader unpacks this code and checks the sum, if
  71. not correct this message will be returned.
  72.  
  73. In addition to that, sorry for my mistake using my pseudonym here.  My
  74. MAIL EXEC did it automaticly, and i thought it wasn't so bad, but i
  75. know now, that this wasn't a joke. Sorry!
  76.  
  77. Thomas Friedrich
  78. University Bonn
  79. Germany
  80.  
  81. ------------------------------
  82.  
  83. Date:      7 April 1989, 14:20:07 EDT
  84. From:      David M. Chess   <CHESS@YKTVMV.BITNET>
  85. Subject:   re: A New Virus Perhaps (PC)
  86.  
  87. That's probably just the Microsoft EXEPACK utility.  It makes smaller
  88. versions of EXE files by compressing them, and sticking on a small
  89. decompresser program.  The decompresser contains the message that you
  90. give, in case something has damaged the compressed version of the
  91. original file.  It comes with many Microsoft compilers, and is not a
  92. virus.
  93.  
  94. Of course, someone COULD have written a virus with that message in
  95. it, just to lull us into trusting it...
  96.  
  97. DC
  98.  
  99. [Ed. Interesting utility - kind of reminds me of Fred Cohen's example
  100. of a Compression Virus.]
  101.  
  102. ------------------------------
  103.  
  104. Date:     Fri, 7 Apr 89 13:54:15 EDT
  105. From:     Fred Hartmann <mhartma@APG-EMH5.APG.ARMY.MIL>
  106. Subject:  Zip "virus" isn't a virus (PC)
  107.  
  108. I checked with Jerry Shenk, SYSOP of Lancaster Area Bulletin Board
  109. (LABB) regarding the possible PKZIP virus and here are his comments:
  110.  
  111. "We have version .92 of PKZIP on-line here and we have version 4.2 of
  112. AM.  The problem was not a virus.  PKZIP has a feature that will allow
  113. it to pass a files attribute to the ZIP and when the file is unZIPped
  114. it will keep that attribute.
  115.  
  116. This has had some rather surprising consequences none of which are
  117. really a virus although they would hog up their share of disk space.
  118. The problem was that a file could contain a hidden file (attribute set
  119. to hidden - nearly everyone has at least two of these such files on
  120. their system...placed there by DOS).  If these files are added to a
  121. ZIP file and that ZIP gets unZIPped to a C:\DUMP and if that is the
  122. directory that is normally used for ZIP unZIP operations the hidden
  123. file(s) will be added to every ZIP that's made from that directory.
  124. It would also be quite easy to pass those hidden files all over the
  125. disk (ie. every place a file was unZIPped.
  126.  
  127. The primary perpetrators of this have been SYSOPs who are converting
  128. files from ARC to ZIP and/or reZIPping for better compression.  I
  129. happen to use a utility for disk management that displays all files
  130. (hidden or not) so I would have spotted it if it had been happening on
  131. LABB.
  132.  
  133. As I understand, Phil is working on a flag that will disable the
  134. 'hidden' flag so that ALL files would be visible if a user wanted it
  135. done that way."
  136.  
  137. ------------------------------
  138.  
  139. End of VIRUS-L Digest
  140. *********************
  141. Downloaded From P-80 International Information Systems 304-744-2253
  142.