home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / org / eff / talk / 8517 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  5.1 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!rutgers!uwvax!gorgon!fullfeed!ruth!rat
  2. From: rat@ruth.UUCP (David Douthitt)
  3. Newsgroups: comp.org.eff.talk
  4. Subject: Beneficial Virus
  5. Message-ID: <m503wB4w165w@ruth.UUCP>
  6. Date: 9 Jan 93 02:58:45 GMT
  7. Organization: Network XXIII - +1 608 222 9253
  8. Lines: 103
  9.  
  10.  
  11. I thought I would give some thought about how a beneficial virus would
  12. be implemented, so that we're all arguing about the same points.
  13.  
  14. One assumption I will be making is that the system(s) are single-user
  15. MSDOS sites - multiuser viruses present a whole new can of worms.
  16.  
  17. First, the user installs the software on their system (System A).  They
  18. run a program called INSTALL.EXE on the provided distribution diskette.
  19. With appropriate warnings and notifications, the install program places
  20. the marker on the system.  It is possible that it would (with notice)
  21. load the compression virus into memory at that time, so that it would
  22. start to spread - or a choice could be given to place the virus on
  23. a file or files, to be activated later (during decompression).
  24.  
  25. One note to be made - the virus being discussed has one purpose: to
  26. spread the decompression routine to as many executables as it sees fit
  27. to.  The decompression routine and the viral infection must be kept
  28. SEPARATE when considering the ramifications of this system.  The decompression
  29. routine could in fact be LZExe or some other, or could even be released
  30. separately from the virus.
  31.  
  32. A file with the virus (and compression code) would operate in this manner:
  33.  
  34.     1. The executable is loaded into memory and run.
  35.  
  36.     2. The first code operates this way:
  37.  
  38.           a. Does viral marker exist?
  39.                 - NO: take your pick of ONE (and ONLY one) of these
  40.                       possibile actions to be taken:
  41.  
  42.                       1. remove virus from file (leaving compression routines
  43.                          in place to decompress file later).
  44.                       2. skip to step 3 - virus remains to activate on other
  45.                          system containing marker.
  46.                       3. remove virus AND COMPRESSION from file.
  47.                       4. ask the user what to do (and choose one of the
  48.                          above or possibly a new install).
  49.  
  50.                 - YES: load the virus (either from file or marker) into
  51.                        memory as a TSR program - with hooks into disk
  52.                        or file read/write/execute.
  53.  
  54.     3. Having executed past the viral code, the decompression routines would
  55.        take hold and decompress the program - virus or no virus.
  56.  
  57.     4. The actual code would then begin to execute.
  58.  
  59. My favorite option under 2. (NO) is to remove the virus entirely.  A virus
  60. would cause too much unnecessary panic otherwise from a misguided and
  61. paranoid public who have heard too many stories which brand hackers as
  62. vicious evil malcontents intent on destroying the world by computer.
  63.  
  64. If the virus was contained in the MARKER, then when a compressed file
  65. leaves the system (such as taking a compressed executable from System A
  66. to System B) there is no virus at ALL present in the file, and the virus
  67. does not spread.
  68.  
  69. Since the virus is not resident in the file, there is not even a chance
  70. of this virus "escaping" a system because the only way the actual code
  71. gets there is by user installation.  If there is an option to install
  72. the virus under 2. (NO) 4., then the viral code must be present in the
  73. compressed file and somebody would probably scream.
  74.  
  75. One possible problem would be a malicious virus masquerading as a
  76. valid marker file.  Then any file compressed with the beneficial
  77. virus would activate the malicious virus - some sort of check would
  78. have to be made that the virus was the *RIGHT* virus.
  79.  
  80. Having considered the infected file, let's consider the virus in operation.
  81. It is assumed that the virus has only been placed in memory after it has
  82. been verified that the marker was present, and it is okay for it to run.
  83.  
  84. The virus might operate this way:
  85.  
  86.    1. The virus recognizes the fact that an executable file is being loaded
  87.       for execution.  How this is done is not particularly relevant, and
  88.       could most likely be done a number of ways.
  89.  
  90.    2. The virus checks for several signatures in the executable (after it has
  91.       been loaded, of course).  This would check whether the file already
  92.       had been compressed (with who knows what), or whether the file had
  93.       the required marker check routine.
  94.  
  95.    3. If the file is not compressed, it would write out to the file on
  96.       disk, in order:
  97.          - the marker check routine
  98.          - the decompression routine
  99.          - the compressed executable
  100.  
  101.    4. It would then delete the original and rename the temporary file to
  102.       be the original.
  103.  
  104. Hope this clears up the viral debate - but I still hope it rages on! :-)
  105.  
  106.  
  107. --
  108. UUCP: ....!fullfeed.com!ruth!rat        |  Network XXIII - +1 608 222 9253
  109. InterNet: rat@ruth.UUCP                 |  80Megs+ of Usenet/Fido programs!
  110. Fidonet: David Douthitt 1:121/23        |  ... Files via Fidonet FREQ,
  111. "...because appealing to the masses has |  anon uucp, first time login,
  112.  never appealed to us."                 |  mail to fileserver@ruth.uucp
  113.