home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / virus / 4880 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  4.2 KB
  1. Path: sparky!uunet!spool.mu.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!cert!netnews.upenn.edu!netnews.cc.lehigh.edu!news
  2. From: SS942TH@dot1.mail.ufl.edu (Tim Hare)
  3. Newsgroups: comp.virus
  4. Subject: Benign "viruses"
  5. Message-ID: <0008.9301121242.AA22066@barnabas.cert.org>
  6. Date: 7 Jan 93 21:28:09 GMT
  7. Sender: virus-l@lehigh.edu
  8. Lines: 63
  9. Approved: news@netnews.cc.lehigh.edu
  10.  
  11. Perhaps I am a bit naive, not being a virus researcher, but could the
  12. problems related to benign virus-like (i.e. self-replicating) programs
  13. be solved by implementing a protocol to control the installation of
  14. self replicating programs? What I envision is something like the
  15. following:
  16.  
  17.      1. Self replicator sends a message to the target machine, asking if
  18.         self replicators are allowed to be installed there. One of several
  19.         things happens:
  20.         A. The target has been set up to allow this to happen automatically,
  21.            go to step 2.
  22.         B. The target might allow it, but must ask for judgement from the
  23.            system administrator (mechanics of "asking" could include E-mail
  24.            to and from administrator, direct interaction, or whatever). If
  25.            the administrator OKs it, go to 2.
  26.            If the administrator doesn't okay it, go to 6.
  27.         C. The system has been set to always deny these requests. Go to 6.
  28.         D. The system doesn't support the protocol. It should not be at risk
  29.            unless it always executes things sent to it from other systems,
  30.            but I don't think this system could be considered completely safe.
  31.            In any event, it cannot participate further in the protocol.
  32.      2. Send an affirmative message to the source (of the replicator) machine,
  33.         inviting the transmission of the program.
  34.      3. Receive the program to a directory that no users except the system
  35.         administrators can access.
  36.      4. Execute whatever security scanning and checking mechanisms are desired
  37.         for this program. If malignancy is detected, notify the administrators
  38.         and stop the process. Do not send negative response messages to the
  39.         source, since this could allow someone to send many small bits of
  40.         malignancy over time and determine exactly what holes your scanning
  41.         and checking procedures allow, then write a self replicator which
  42.         passes all your tests but is still malignant.
  43.      5. If it looks OK, move the program the place where it should be executed.
  44.         I would propose that all such self-replicating programs from one area
  45.         under one user identification, and that that user have the lowest
  46.         possible rights on that system, and _no_ rights to create or modify
  47.         files. Reading files and sending messages should be allowed.
  48.      6. Error situations: Send a negative response and stop.
  49.  
  50. The advantages I see to this are that self-replicating programs can be used
  51. where they will be benificial, but _cannot_ be used without the permission
  52. of the system administrators. Step 4 will help make sure that the program is
  53. not malignant (obviously dependent upon the quality of your checking), and
  54. following the caveats in step 5 should prevent it from modifying files or
  55. data (well at least it will be no more capable than a program installed by the
  56. system administratos). Once the program has been installed, in fact, the
  57. security problem is about the same as that for programs written at the site,
  58. and looks identical (to me) to the security problems for programs obtained
  59. from other sites by FTP, download, or purchase. Allowing it to send messages
  60. does mean that someone could send all your sensitive data back to themselves,
  61. but your sensitive data should already be protected from being read by any
  62. old program, anyways.
  63.  
  64. Like I said earlier, I'm not a researcher, so my theoretical groundings are not
  65. very good. Any and all comments on this are welcomed. My thoughts on this are
  66. mainly due to a desire to someday see the fabled "knowbot" which can hunt
  67. around on "the net" for information on a particular topic, following leads to
  68. different sites as necessary.
  69.  
  70. Regards
  71. Tim Hare
  72. Systems Programmer
  73. Florida Department of Transportation ("Potholes Built and Fuilt While-U-Wait")
  74.