home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.21 < prev    next >
Text File  |  1995-01-03  |  9KB  |  204 lines
  1. VIRUS-L Digest              Monday, 23 Jan 1989         Volume 2 : Issue 21
  2.  
  3. Today's Topics:
  4. re: PDP virus
  5. Size-changing viruses
  6. Re: 1st and 2nd Main propositions of virus hunting
  7. Anti-virus programs
  8. RE: Otto's Rules
  9.  
  10. ---------------------------------------------------------------------------
  11.  
  12. Date: Fri, 20 Jan 89 16:46:52 EST
  13. From: shafferj@amethyst.bucknell.edu
  14. Subject: re: PDP virus
  15.  
  16. I haven't seen any PDP viruses, but the Cookie Monster seems to be a
  17. classic program.  I wouldn't call it a virus -- at least, I've never
  18. heard of any viral versions.  It's probably something someone inserted
  19. when no-one else was looking.  Unless the perpetrator manages to patch
  20. the operating system, you should be able to find the file somewhere
  21. and delete it.  Also, you should be able to find the process (task?
  22. I'm not very familiar with PDP terminology, and you didn't mention
  23. which OS you were running on it anyway) and kill it.  Unless this is
  24. an exotic version, it should be very easy to get rid of the problem.
  25.  
  26. Jim
  27.  
  28. ------------------------------
  29.  
  30. Date: Sun, 22 Jan 89 15:22:22 PST
  31. From:     PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet
  32. Subject: Size-changing viruses
  33.  
  34. I gather that at least some of the virus-detection programs on the
  35. market recognise viruses by looking for files or file extensions of
  36. specific sizes.  What happens when a virus comes out which changes its
  37. size with each infection according to a random number table?
  38.  
  39. Peter Scott (pjs@naif.jpl.nasa.gov)
  40.  
  41. ------------------------------
  42.  
  43. Date: Sat, 21 Jan 89 21:37:34 PST
  44. From: crocker@tis-w.arpa
  45. Subject: Re: 1st and 2nd Main propositions of virus hunting
  46.  
  47. In vol 2, # 20, Otto Stolz gives two propositions of virus hunting,
  48. viz. (1) every program designed to catch viruses can be circumvented
  49. by virus-writers who know its principles of operation, and (2) every
  50. virus can be [caught] and prevented from further propagating if its
  51. principles of operation are known.
  52.  
  53. These principles help characterize virus hunting as a game, in the
  54. theoretical sense, but they include an implicit assumption that is
  55. worth examining.
  56.  
  57. A "virus-hunter" can be viewed as a filter.  The user presents to the
  58. filter a set of programs and asks it to separate out the programs that
  59. have viruses from the ones that don't.  This is the same paradigm as
  60. trying to sort out, say, bad ball bearings from a manufacturing
  61. process using some sort of test, and there four classical outcomes.
  62.  
  63. 1. A truly good part will be seen to be good.  [Translation, a
  64.    virus-free program will be seen to be virus-free.]
  65.  
  66. 2. A truly bad part will be seen to be bad.  [Translation, a program
  67.    which contains a virus will be detected.]
  68.  
  69. 3. A truly bad program appears to be good.  This is a "false
  70.    acceptance," or in the lingo of statistics, a Type II error.
  71.    [Translation, a program which contains a virus slips through the
  72.    filter.]
  73.  
  74. 4. A truly good program appears to be bad.  This is a "false
  75.    rejection," or a Type I error.  [Translation, a program which is ok
  76.    is rejected unfairly.]
  77.  
  78. Only a perfect test will have no false acceptances and no false
  79. rejections.  Less than perfect tests must necessarily have some
  80. combination of these errors.
  81.  
  82. Now the critical contribution from the world of statistics is that it
  83. is almost always possible to trade off Type I for Type II errors.
  84. Looking at only the Type I or only the Type II error rate doesn't tell
  85. enough about the power of the test.  When comparing two different
  86. tests, e.g. whether to use, say x-ray screening or a mechanical test
  87. on ball bearings, one test is superior to another only if it yields
  88. lower error rates for BOTH Type I and Type II errors.
  89.  
  90. How does this apply to virus hunting programs?  There are two ways a
  91. virus hunting program can fail.  It can reject good programs or it can
  92. pass bad programs.  So far as I can tell, virus hunting programs are
  93. generally written with the implicit assumption that it is unacceptable
  94. to reject a good program.  That is, they strive to have a very low
  95. (ZERO?) false rejection rate.  As these tests are also less than
  96. perfect, they necessarily have a significant false acceptance rate,
  97. i.e. they fail to detect some programs that have viruses.
  98.  
  99. If the tolerance for false rejections were changed, i.e. if it became
  100. acceptable to reject some programs which are really ok, then it is
  101. entirely possible to build a virus hunter than cannot be circumvented.
  102. At the extreme, rejecting EVERY program surely catches every virus,
  103. but that throws the baby out with the bath water.  The interesting
  104. question is how much better can we do?
  105.  
  106. As long as we are faced with imperfect tests, we will necessarily have
  107. to live with non-zero error rates.  Nothing forces us to have these
  108. errors be only false acceptances.  We can choose to have only false
  109. rejections, if we wish.  [We can also choose to have a combination,
  110. but let me ignore that in this note.]  Only when we apply some sort of
  111. cost function can we choose appropriately.
  112.  
  113. Now, it might seem to readers of this forum that having a fail-safe
  114. test would necessarily result in too many false rejections.  This is
  115. indeed a relevant question, but I don't think any of us know what the
  116. answer is.  It may well be possible to write a fail-safe virus hunter
  117. that examines the innards of a candidate program to decide if it's ok,
  118. and that most of the genuinely ok programs actually pass the test.
  119.  
  120. In the current world, where there are no ground rules for writing
  121. programs to make them easy to examine, Stolz' principles indeed
  122. characterize the situation for virus hunting programs that are not
  123. permitted to reject good programs.  There are two ways to change the
  124. game, however.
  125.  
  126. 1. Permit virus hunting programs to declare a program "unsafe" if it
  127.    cannot PROVE that there is no virus.
  128.  
  129. 2. Set forth standards for programs to facilitate examination by this
  130.    new class of virus hunters.
  131.  
  132. The first proposal, taken alone, may or may not be practical.  I do
  133. not know how hard it is to write an acceptably accurate virus filter
  134. that works on software prevalent today.  Some of my colleagues think
  135. it is obviously too hard.  My own view is that it may well be easier
  136. that it first seems to be.  In either case, I don't think there's
  137. enough data, and I believe it would be worthwhile exploring the
  138. question.
  139.  
  140. The latter proposal is much easier from a technical standpoint but
  141. involves creation and promulgation of standards.  In the long run,
  142. this may be the way we ultimately develop the means to trust the
  143. software we depend on.
  144.  
  145. These ideas are taken from a paper Maria Pozzo and I have written, "A
  146. Proposal for a Verification-Based Virus Filter," which is being
  147. presented at the 1989 IEEE Symposium on Research in Security and
  148. Privacy, Oakland, May 1-3.
  149.  
  150. The ideas expressed here are mine, and do not necessarily -- and in
  151. some cases are known not to -- represent those of my colleagues, any
  152. of our clients or sponsors, or the official position of Trusted
  153. Information Systems.
  154.  
  155. Steve Crocker
  156. Vice President
  157. Trusted Information Systems
  158.  
  159. ------------------------------
  160.  
  161. Date:         Sat, 21 Jan 89 16:18:08 +0200
  162. From:         "Yuval Tal (972)-8-474592" <NYYUVAL@WEIZMANN.BITNET>
  163. Subject:      Anti-virus programs
  164.  
  165. I have a few good PUBLIC DOMAIN programs that checks if you have a
  166. virus on a disk or in yuour memory. it is also possible to tell the
  167. program to check your disk every X time if your hard disk is infected
  168. by a virus.  Some of you probly heard of them:
  169.  
  170. IMMUNE, UNVIRUS, VIRALARM, RUNTIME, BB-VIRUS, CHKVIRUS etc...
  171.  
  172. Who wants them can send me mail and i'll be happy to send them...
  173.  
  174. Yuval Tal (NYYUVAL@WEIZMANN.BITNET)
  175.  
  176. ------------------------------
  177.  
  178. Date:         Fri, 20 Jan 89 23:03:14 EST
  179. From:         Neil Goldman <NG44SPEL@MIAMIU.BITNET>
  180. Subject:      RE: Otto's Rules
  181.  
  182. To put it another way, as Fred Cohen has said (i believe):
  183.  
  184. In general, it is impossible to detect viruses, but any particular
  185. virus can be detected by a particular detection scheme.
  186.  
  187. I believe it is the ignorance of not only the general public, but also
  188. computer professionals that compounds the perception that somewhere
  189. out there exists a cure-all.  Everything WE CAN DO TO EDUCATE virus
  190. inquirers of Otto's rules, the LESS the hysteria will continue.
  191.  
  192. - ----------------------------------------------------------------------
  193. Neil A. Goldman                        NG44SPEL@MIAMIU.BITNET
  194.  
  195. Replies, Concerns, Disagreements, and Flames expected.
  196. Mastercard, Visa, and American Express not accepted.
  197. Acknowledge-To: <NG44SPEL@MIAMIU>
  198.  
  199. ------------------------------
  200.  
  201. End of VIRUS-L Digest
  202. *********************
  203. Downloaded From P-80 International Information Systems 304-744-2253
  204.