home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / virus / 4873 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  4.2 KB
  1. Path: sparky!uunet!think.com!yale.edu!jvnc.net!netnews.upenn.edu!netnews.cc.lehigh.edu!news
  2. From: grweiss@phoenix.princeton.edu (Gregory Robert Weiss)
  3. Newsgroups: comp.virus
  4. Subject: Re: Good use of (possible bad) viruses
  5. Message-ID: <0020.9301071651.AA16031@barnabas.cert.org>
  6. Date: 6 Jan 93 16:50:11 GMT
  7. Sender: virus-l@lehigh.edu
  8. Lines: 84
  9. Approved: news@netnews.cc.lehigh.edu
  10.  
  11. celustka@sun.felk.cvut.cs (Celustkova-k336-doktorand(Richta)) writes:
  12. >Hi boys and girls, (a day of inspiration,huh ?)
  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). 
  26.  
  27. Developing solutions for anticipated problems is quite reasonable; however,
  28. the following statement isn't:
  29.  
  30. >If such virus *by
  31. >accident* escape from my lab I already have a response and there is no
  32. >ethical problem at all.
  33.  
  34. No problems if it "accidently escapes"...
  35.  - unless of course you developed the virus and it "escaped by accident" 
  36.      before you had your A-V program properly detecting it.  
  37.  - unless you think about the fact that most people will not use *your* A-V
  38.      program, they'll use someone else's, or maybe even no protection at all.
  39.  - unless you consider that and you will create a lot of work for 
  40.      other A-V writers, and damage to others in the meantime.
  41.  
  42. These problems are both technical and ethical problems that you must
  43. confront before doing this kind of work, IMHO.  
  44.  
  45. >2. Viruses built in an A-V product (it's just an idea, don't blame me if it
  46. >is not applicable in reality)
  47. >
  48. >Suppose that we have an A-V product which in regular intervals or
  49. >randomly send a virus in system. Virus (fast infector) infects only
  50. >programs which checksum doesn't correspond to previously calculated
  51. >values. If no such program is found virus deletes itself or removes
  52. >from memory. If changed program found virus activates scanner to check
  53. >if there is any known virus.  If known virus is found message is sent
  54. >to the user. If program is changed and no known virus is found the
  55. >message is sent to the user to make decision.  
  56.  
  57.      This sounds fine and good for a strictly contained system owned by an
  58. A-V writer (note the dangers mentioned in my previous comment above),
  59. but will be *absolutely, fundamentally worthless* in an A-V product
  60. as you describe, because you are describing a system in which the 
  61. virus is discovered (and hopefully removed) only *after* files have been
  62. damaged.  The point of having A-V products is to prevent the damage in 
  63. the first place.
  64.   
  65.      So now my financial records which I hadn't backed up for a
  66. month or two (or more...) are damaged: my A-V virus says the checksum has
  67. changed.  Well, I'm glad that I caught that virus, even though it destroyed
  68. the data file I was trying to protect! :-)
  69.  
  70.      The reason why many A-V products are TSRs is to catch viruses *as* they
  71. enter the system, not *after* they enter the system.  Your A-V virus
  72. seems to fall short in this regard.
  73.  
  74. >                        If decision is to leave
  75. >program as is, virus cuts itself from the program.  The whole process
  76. >(except messages) takes place in background. There is no need for all
  77. >A-V program (which is combination of I-checker and scanner) to be TSR,
  78. >only virus is occasionally TSR. There is slight similarity in this
  79. >idea with reaction of human immunity system. Anyone has ethical
  80. >problem with her/his own immunity system ?
  81.  
  82. I understand your comparison is tongue-in-cheek, but you really are comparing
  83. apples and oranges here.  In the immune system, a few cells can die, but
  84. your body can still function properly.  Computer data files and programs 
  85. are much less forgiving of a few errors.
  86.  
  87. >Cheeeers,
  88. >
  89. >Suzana                                                                   
  90.  
  91. Happy New Year everyone!
  92.  
  93.   --Greg
  94.     grweiss@phoenix.princeton.edu
  95.