home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.64 < prev    next >
Text File  |  1995-01-03  |  6KB  |  140 lines

  1. VIRUS-L Digest             Tuesday, 14 Mar 1989         Volume 2 : Issue 64
  2.  
  3. Today's Topics:
  4. Virus hysteria.
  5. Re: PC Boot Sector Viruses
  6. Reply on notarization
  7. File lock protection?  (Mac)
  8.  
  9. ---------------------------------------------------------------------------
  10.  
  11. Date:     Mon, 13 Mar 89 08:40 EST
  12. From:     Cincinnati Bengals. <KUMMER@XAVIER.BITNET>
  13. Subject:  Virus hysteria.
  14.  
  15.      I was wondering if anyone has comments on the way reports of
  16. viruses seem to be given too much attention by the media.  As an
  17. example, when our Mac's were hit by the nVIR virus, a local newspaper,
  18. the Cincinnati Post, place a report of the virus on the front page.
  19. The virus was a relatively minor occurance, start-ups were being
  20. disabled, applications were being altered, but no loss of data.
  21. Surely this is newsworthy, but front page?  This seems comparable to
  22. placing reports on the front page every time the common cold breaks
  23. out on campus.  Comments?
  24.  
  25. Tom Kummer
  26.  
  27. ------------------------------
  28.  
  29. Date: 13 Mar 89 22:14 -0100
  30. From: Jeff Raynor <raynor%rzsin.sin.ch@cernvax.BITNET>
  31. Subject: Re: PC Boot Sector Viruses
  32.  
  33.       In issue #61, Y.  Radai discusses the "bouncing ball" virus and
  34.  its spread outside of his area to other European countries.
  35.  
  36.       This made me think about the transmission method of these
  37. beasts.  A straight-forward boot sector virus would only be spread by
  38. the boot sector (physical media) and so wouldn't propogate across
  39. serial lines ("electronic media": modems, BBS, "long distance"
  40. networks) - but might on local nets.
  41.  
  42.       I would be interested to hear from those unfortunate to be
  43. infected:
  44.  
  45.       Was the infection via an infected disk?
  46.       Was the "culprit" disk identified?
  47.       Was the disk created by a user?
  48.       Was the disk formatted by a user?
  49.       Was the disk from a software house?
  50.       Was the disk received by post or by person?
  51.  
  52.       I realize that its naive to assume that you can only get
  53. infected with .EXE viruses via a line or boot sectors with physical
  54. media.  I would have thought that the disadvantage of propagation of
  55. the boot sector types would have favoured the .EXE types.  However,
  56. most of the PC viruses currently causing damage seem to be the boot
  57. sector types.  Anyone in netland like to comment?
  58.  
  59.       Jeff Raynor
  60.  EAN:  RAYNOR%RZSIN.SIN.CH
  61.  Paul Scherrer Institut, Zurich, Switzerland.
  62.  
  63. ------------------------------
  64.  
  65. Date:     Mon, 13 Mar 89 17:49:05 EST
  66. From:     Jefferson Ogata (me!) <OGATA@UMDD.BITNET>
  67. Subject:  Reply on notarization
  68.  
  69. >  ....  Many mechanisms can be used to protect the software that
  70. > might check a "cryptographically sealed" program.  The simplest
  71. > is to restart a computer with the verification software on a disk
  72. > with the write protect tab set.  Other schemes are possible and
  73. > are independent of the cryptography and data formats.
  74.  
  75. That's fine if you only want to check things once in a while; but what
  76. are these other schemes?  And how do you protect your operating
  77. system?  And you're ignoring the context of the remark: keeping
  78. programs in an encrypted state until execution.  Surely you don't
  79. propose to reboot the computer every time a program is executed.  The
  80. difference between keeping programs in an encrypted state and just
  81. computing signatures on them is that the former actually deters the
  82. spread of a virus, while the latter merely allows you to detect it.
  83.  
  84. > I am proposing a hierarchical notarization system...
  85.  
  86. I must assume you are referring to the type of system described
  87. (rather lucidly) in the last issue by William Murray, which
  88. relies upon an already existing network of trusted sources.  I
  89. can see this as viable in some ways.  But I'm not clear on how
  90. it would help the average user who has very few "trusted" sources.
  91. Even software houses have distributed viruses inadvertantly of
  92. late.
  93.  
  94. >>   ...  Such signatures would be just as easily corrupted as the
  95. >> programs in question.
  96. > Wrong.  Read any recent article on public key cryptography.
  97.  
  98. Public-key cryptography works fine when you have a method of
  99. distributing the decryption key uncorrupted.  But in the case of
  100. a signature list coming from a bulletin board (for example),
  101. using a public-key method just abstracts the problem one more step.
  102. You STILL need a clean channel for transmitting the decryption key;
  103. else anyone can modify a decrypted version of the signature file,
  104. encrypt it again with another public key set and distribute the
  105. new decryption key with the new signature file.  This is a trivial
  106. step for anyone who actually desires to modify the signature file.
  107. Public-key cryptography is just begging the question.  And once
  108. again, if you have this uncorruptable method for transmitting the
  109. decryption key, you may as well transmit something simpler, like
  110. file size, various checksums and crcs, or the entire program.  It
  111. again boils down to whom you can trust.
  112.  
  113. - - Jeff Ogata
  114.  
  115. ------------------------------
  116.  
  117. Date: Mon, 13 Mar 89 16:48 EST
  118. From: "Mark H. Anbinder" <THCY@VAX5.CCS.CORNELL.EDU>
  119. Subject: File lock protection?  (Mac)
  120.  
  121. MacUser magazine reported in the Tip Sheet section of their April
  122. issue that locking individual files using the Locked bit of the Finder
  123. info (using the Locked button in the Get Info window, or a file
  124. utility program) will prevent virus infection.  I don't remember
  125. whether they said "prevent" or "help prevent," so please don't correct
  126. me if I missed a word.
  127.  
  128. My question -- will this really accomplish anything?  Can any known
  129. viruses infect an application file that has its Locked bit set?
  130.  
  131. Mark H. Anbinder
  132. Department of Media Services
  133. Cornell University
  134.  
  135. ------------------------------
  136.  
  137. End of VIRUS-L Digest
  138. *********************
  139. Downloaded From P-80 International Information Systems 304-744-2253
  140.