home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / virus / 4981 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  5.0 KB

  1. Path: sparky!uunet!ukma!darwin.sura.net!newsserver.jvnc.net!netnews.upenn.edu!netnews.cc.lehigh.edu!news
  2. From: RADAI@vms.huji.ac.il (Y. Radai)
  3. Newsgroups: comp.virus
  4. Subject: Re: On the definition of viruses
  5. Message-ID: <0003.9301271940.AA16908@barnabas.cert.org>
  6. Date: 18 Jan 93 15:06:10 GMT
  7. Sender: virus-l@lehigh.edu
  8. Lines: 78
  9. Approved: news@netnews.cc.lehigh.edu
  10.  
  11.  
  12.   Albert Lunde writes:
  13. > Fred Cohen can point with justified pride to the mathematical theory
  14. > of viruses.  At the same time, I think it is perfectly understandable
  15. > that people will use more relative, subjective critera based on a
  16. > perception of risk and intention. This is especially the case since
  17. > one of the consequences of the mathematical theory is a proof that a
  18. > general "unknown virus" detector is impossible!
  19.  
  20. You don't need Fred's mathematical theory to show that.  It's also a
  21. consequence of any reasonable informal (natural-language) definition
  22. of "virus", as Fred himself has shown.  Since his informal proof has
  23. been presented on Virus-L/comp.virus at least five times, I won't
  24. bother restating it here.  However, I'd like to present an argument
  25. which I thought of a couple of years ago, which demonstrates (at least
  26. for all practical purposes) the undecidability of whether a given
  27. program contains a virus, in a completely different way from Fred's
  28. proof (the one based on the proof of the undecidability of the Halting
  29. Problem on a Turing Machine), a way which seems to me far more intui-
  30. tive, even if it's not quite as conclusive.
  31.   Suppose a program contains code for replication, but only within a
  32. statement of the form "If <condition> then <replicate>", where
  33. <condition> is something which depends on the run-time environment,
  34. e.g. on the input which a user supplies.  Can a detection program
  35. discover whether the program actually does replicate?
  36.   To illustrate the generality of the situation, I'll even offer a
  37. choice between three reasonable informal definitions of "virus":
  38. (a) a virus is a sequence of instructions which replicates on *every*
  39.     execution;
  40. (b) a virus is a sequence of instructions which replicates on *at
  41.     least one* execution;
  42. (c) A sequence of instructions is a virus in a given run-time environ-
  43.     ment if and only if it replicates in that environment.
  44.   If the decision is to be made by appearance of the program alone,
  45. then the simplest case is (c), for suppose that the program asks the
  46. user to supply two numbers, x and y, and <condition> is "x < y".  Then
  47. it is completely obvious that fulfillment of this condition cannot be
  48. determined without actually running the program, hence whether the
  49. program is a virus is undecidable by appearance of the program alone.
  50. Note that this argument does not require the assumption that the
  51. computer has an infinite amount of storage, as Fred's proof does.
  52.   If the definition is (a) or (b), then we can do even better: we can
  53. show that in some cases the question cannot be decided even by running
  54. the program any finite number of times.  For example, suppose the
  55. program asks the user to input four positive integers i, j, k, n
  56. (where n must be > 2).  If you choose definition (b), I shall take
  57. <condition> to be "i^n + j^n = k^n".
  58.   Now for all anyone knows, it may be that this condition is *never*
  59. actually satisfied.  (The statement that there are no such integers is
  60. Fermat's "Last Theorem", for which he *claimed* he had found a proof,
  61. but he didn't produce it and no mathematician since him has found
  62. either a proof or a counter example.)  Not only can we not decide this
  63. by appearance of the program, but even if we run this program a zil-
  64. lion times and the program doesn't replicate, that doesn't prove that
  65. it can *never* replicate; all one can say is that the program hasn't
  66. replicated *so far*.
  67.   If you choose definition (a) instead, I take <condition> to be the
  68. negation of the above statement, and the same argument works.
  69.   In any case, there are some situations in which you can't decide
  70. whether a given program is a virus.  We can substitute for Fermat's
  71. Theorem any other unsolved problem.  If you could write a program
  72. which could decide whether the resulting programs are viruses, then
  73. you would become famous for having solved all the world's heretofore
  74. unsolved problems!!  (Well, at least those which can be expressed by a
  75. computer program.)  Thus it is intuitively clear that the property of
  76. virality is undecidable, at least for all practical purposes.
  77.   Of course, one can take the position that it's just an historical
  78. accident that these problems have not yet been solved, and that in
  79. principle they may all be solved some day.  However, it can be shown
  80. that there are infinitely many problems which can *never* be solved
  81. (although that apparently requires use of one of those "paradoxical"-
  82. type proofs which I've been trying to avoid here).
  83.   Comments are welcome (especially Fred's).
  84.  
  85.                                      Y. Radai
  86.                                      Hebrew Univ. of Jerusalem, Israel
  87.                                      RADAI@HUJIVMS.BITNET
  88.                                      RADAI@VMS.HUJI.AC.IL
  89.