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

  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!cert!netnews.upenn.edu!netnews.cc.lehigh.edu!news
  2. From: RADAI@vms.huji.ac.il (Y. Radai)
  3. Newsgroups: comp.virus
  4. Subject: Re: Good use of (possible bad) viruses
  5. Message-ID: <0004.9301121242.AA22066@barnabas.cert.org>
  6. Date: 7 Jan 93 15:37:53 GMT
  7. Sender: virus-l@lehigh.edu
  8. Lines: 65
  9. Approved: news@netnews.cc.lehigh.edu
  10.  
  11.  
  12.   Suzana S.-C. [sorry, I can't cope with such a long name] writes:
  13.  
  14. > Just one of those days...Two examples of good use of (possible bad)
  15. > viruses come to my mind :
  16. >
  17. > 1. Viruses written to improve an A-V product
  18. >
  19. > The logic is simple. It is better that I write virus which can do this
  20. > or that and have prepared solution to implement in my A-V product than
  21. > wait that such virus arises in wild and then react. That means if I
  22. > know that today exist viruses which could be stealthy, tunneling or
  23. > polymorfic why shouldn't I write virus which is all that and design my
  24. > A-V product to recognize such virus before it really appears in wild.
  25. > (Well, maybe it is not commercial, I don't know). If such virus *by
  26. > accident* escape from my lab I already have a response and there is no
  27. > ethical problem at all.
  28.  
  29. You definitely should try to anticipate new types of viruses.  But
  30. why do you have to *write a virus* to do this?  It's certainly
  31. pointless in the case of scanners, and in the case of other types of
  32. AV software, it's usually sufficient to *think* of what a new type of
  33. virus might do, and to modify your AV product accordingly, without
  34. actually writing such a virus.  (And if your virus does escape by
  35. accident, it would suggest irresponsibility on your part, so I think
  36. you *would* have an ethical problem.)
  37.  
  38.   (Btw, although this evidently was not what you were referring to,
  39. it reminds me of a few cases I have heard of in which the authors of
  40. a known-virus scanner have written a new virus and inserted a corres-
  41. ponding pattern into their scanner, so that the virus is detectable
  42. by their scanner but not by their competitors' scanners.  They then
  43. adduce this as "proof" that their product is better than those of
  44. their competitors.  Needless to say, this would be highly unethical
  45. in the opinion of most people.)
  46.  
  47. > 2. Viruses built in an A-V product (it's just an idea, don't blame me if it
  48. > is not applicable in reality)
  49. >
  50. > Suppose that we have an A-V product which in regular intervals or
  51. > randomly send a virus in system. Virus (fast infector) infects only
  52. > programs which checksum doesn't correspond to previously calculated
  53. > values. If no such program is found virus deletes itself or removes
  54. > from memory. If changed program found virus activates scanner to check
  55. > if there is any known virus.  If known virus is found message is sent
  56. > to the user. If program is changed and no known virus is found the
  57. > message is sent to the user to make decision.  If decision is to leave
  58. > program as is, virus cuts itself from the program.  The whole process
  59. > (except messages) takes place in background. There is no need for all
  60. > A-V program (which is combination of I-checker and scanner) to be TSR,
  61. > only virus is occasionally TSR. There is slight similarity in this
  62. > idea with reaction of human immunity system. Anyone has ethical
  63. > problem with her/his own immunity system ?
  64.  
  65. I'm afraid I don't understand this one at all.  What's the advantage
  66. of infecting files?  Just so that the I-checker and scanner don't have
  67. to be resident?  There are lots of I-checkers and scanners which are
  68. *non-resident*.  Not only does that save memory, but it's also a more
  69. secure way of doing things.  The advantage of your proposal seems to
  70. me completely outweighed by the risks involved.
  71.  
  72.                                      Y. Radai
  73.                                      Hebrew Univ. of Jerusalem, Israel
  74.                                      RADAI@HUJIVMS.BITNET
  75.                                      RADAI@VMS.HUJI.AC.IL
  76.