home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8629 < prev    next >
Encoding:
Text File  |  1993-01-12  |  4.7 KB  |  109 lines
  1. Newsgroups: comp.org.eff.talk
  2. Path: sparky!uunet!gatech!emory!nastar!phardie
  3. From: phardie@nastar.uucp (Pete Hardie)
  4. Subject: Re: Beneficial Virus?
  5. Message-ID: <1993Jan12.145749.10560@nastar.uucp>
  6. Organization: Digital Transmission Systems, Duluth, GA.
  7. References: <C0Ky6z.HsB@panix.com> <1993Jan11.163720.6604@nastar.uucp> <C0psLo.KLx@panix.com>
  8. Date: Tue, 12 Jan 1993 14:57:49 GMT
  9. Lines: 98
  10.  
  11. In article <C0psLo.KLx@panix.com> rpowers@panix.com (Richard Powers) writes:
  12. >The BCV would need to use _some_ method to search for files to infect.
  13. >It would be trivial to restrict this to searching only what belongs to
  14. >the user who placed it on the multi-user system.
  15.  
  16. Perhap it is trivial.
  17.  
  18. Another thought occurs - when does the virus infect an executable?  When
  19. the executable is next run (virus is a TSR), or the first time an infected
  20. program is run (virus is part of executable).  The latter case can introduce
  21. long delays in execution of the 'real' program.
  22.  
  23. >I don't really see the BCV as being usefull to an individual user on a
  24. >multi-user system.  Users usually don't own their own executables, for
  25. >one thing.
  26.  
  27. Au contraire.  UNIX executables are owned by the user.  I believe that VMS
  28. executables are owned by the user running the compile.
  29.  
  30. >>Again, if we are talking about use on one system, the BCV is not a problem
  31. >>for the installer, and almost never a problem for anyone else.  
  32. >
  33. >Exactly!  These *are* the circumstances which I had in mind when
  34. >proposing this.
  35.  
  36. OK, this is an agreement point.
  37.  
  38. >>Once we are
  39. >>discussing 2+ machines, it *can become* a problem for the other users, since
  40. >>they suddenly find a section of code *that they did not write* residing in
  41. >>their executables, and asking them questions about a file *they may know
  42. >>nothing about*.
  43. >
  44. >But I contend that all that is necessary is for the BCV to be used
  45. >responsibly.  The design should make it easier for this to be so (the
  46. >marker file, etc.), and minimize any problems that could occur.
  47.  
  48. And I keep saying that if it acts like a virus, it de facto cannot be 'used'
  49. responsibly, since 'use' is not controlled by the user.
  50.  
  51. >>I'm not clear on this.  If the marker file is present, and I do not have
  52. >>any executables from before, how do I know?  
  53. >
  54. >You are talking about a multi-user system in this case, yes?  "See
  55. >above."  Refers to my discussion of the sysadmins responsibility to
  56. >inform his/her users of the presence of the BCV.
  57.  
  58. But what about the case where the sysadmin is not the installer?
  59.  
  60. >But the BCV could (and should) be made to restrict itself to the
  61. >owning users files.
  62.  
  63. How will the virus be able to tell that the user's files are his/hers on
  64. another system?  User id's are different, and not all are equally certain
  65. to be unique.
  66.  
  67. >No, I understand what you are saying.  I still don't think _you_ get
  68. >my point.  Just because the program exhibits behavior that is right
  69. >now exclusively(?) used by programs which exist only as a nuisance (at
  70. >best), or are actually dangerous, does not mean that this should
  71. >reflect on _every_ program which has _some_ similar characteristics.
  72. >The particular methods any program uses can be debated for and
  73. >against.  (Is it a bug or is it a feature?)  What I'm saying is that
  74. >the characteristics which we say typify(sp?) as virus charecteristics
  75. >do _not_ prohibit a program from being beneficial.
  76.  
  77. Let me try again.
  78.  
  79. The BCV _is_ a virus.  It compresses my files w/o my knowledge, just like
  80. a device driver.  But it can arrive on my system and affect files that I
  81. did not want affected.  Thus it no longer is _beneficial_.  And that is
  82. the problem.  It does not affect ALL programs, which would be at least
  83. noticeable, but only some, and only at a later date (execution).
  84.  
  85. If I am trying to make an executable that will exactly fill a single floppy
  86. disk, your BCV is harmful to my goal, since it will allow a larger program
  87. to be placed on the disk, and then at some later date it might be decompressed
  88. and no longer fit.
  89.  
  90. >>It is the assumption that you (or the virus writer) know better than I what
  91. >>is beneficial to my system/files that is the problem.
  92. >
  93. >I don't understand why you think anyone is assuming this.  This is no
  94. >more the case with the virus writer (beneficial type) than with any
  95. >other programmer whose programs are used on systems other than his
  96. >own.
  97.  
  98. But other programs either a) run all the time, which means that the admin
  99. can control their presence, or b) are run only by explicit invocation, which
  100. means the user wants them to run.  The BCV runs in a 'hidden' manner, affecting
  101. programs beyond the original one in an indeterminate manner (to the user)
  102.  
  103.  
  104. -- 
  105. Pete Hardie:  phardie@nastar  (voice) (404) 497-0101
  106. Digital Transmission Systems, Inc., Duluth GA
  107. Member, DTS Dart Team           |  cat * | egrep -v "signature virus|infection" 
  108. Position:  Goalie               |
  109.