home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.135 < prev    next >
Text File  |  1995-01-03  |  15KB  |  298 lines

  1. VIRUS-L Digest              Monday, 12 Jun 1989        Volume 2 : Issue 135
  2.  
  3. Today's Topics:
  4. Net Hormones: Analysis needed. , Net Hormones Paper by David S. Stodolsky
  5. Re: naming confusion
  6. RE: software industry vs. viruses
  7.  
  8. ---------------------------------------------------------------------------
  9.  
  10. Date:    11 Jun 89 12:13:31 GMT
  11. From:    stodol@diku.dk (David Stodolsky)
  12. Subject: Net Hormones: Analysis needed.
  13.  
  14. - ----->      Net Hormones feasibility: Analysis needed.
  15.  
  16. - -----> Message forwarded from:
  17.  
  18. VIRUS-L Digest              Friday, 28 Apr 1989        Volume 2 : Issue 102
  19. Date:    Fri, 28 Apr 89 11:59:11 MDT
  20. From:    Chris McDonald <cmcdonal@wsmr-emh10.army.mil>
  21. Subject: Net Hormones Paper by David S. Stodolsky
  22.  -----> (1989a [in references below])
  23.  
  24. I read with interest the subject paper which resulted in some questions.
  25.  
  26. First, if contact tracing is technically possible among hosts and
  27. networks, is the proposed "theory of operation" described in paragraph
  28. 4 of the paper really practical?
  29.  
  30. - ----->That is the question. In section 6,  "Feasibility and Efficiency,"
  31. Stodolsky (1989a) states:
  32.  
  33. Contact tracing is probably most effective for sparsely interacting
  34. hosts.  The rate of transfer of the infectious agent as compared to
  35. the rate of transfer of the suspect transaction codes is also a
  36. critical factor.  Recording of transactions can be comprehensive on
  37. computer networks, however, unregistered transactions will be a factor
  38. in most cases. Once the infectious agent has been identified, the type
  39. of transactions capable of transmitting the agent can be delimited.
  40. This could increase efficiency.
  41.  
  42. - ----->Someone very familiar with the interaction of hosts on the main
  43. networks and with common infections (maybe the Internet Worm would be a
  44. good case for a start) must look at these factors ( and no doubt others)
  45. before any real estimate of practicality can be made. An epidemiologist
  46. will at least have to check the results, these problems are pretty tricky.
  47.  
  48. Dr. Stodolsky proposes that: "In the
  49. event that a system is identified as infected, the transaction codes
  50. which could represent transactions during which the agent was
  51. transmitted are broadcast to all other computers."  The words "which
  52. could represent transactions" suggests that an attack which used a
  53. delay mechanism or "time bomb" approach would make it extremely
  54. difficult to identify suspect transactions in a timely manner.
  55.  
  56. - -----> I'll bet that on a net of a million machines, somebody would
  57. set their clock wrong or see the agent by accident if there was a long
  58. delay. I hope the National Security Agency could spot something like
  59. this, at least for their own protection. However, I wonder whether the
  60. pseudonym-based reputation mechanism proposed would give them
  61. sufficient incentive to go public with their discovery.
  62.  
  63. It might also suggest that the historical record of transactions would
  64. of necessity be inordinately large and for practical reasons might be
  65. difficult to implement.
  66.  
  67. - -----> Yes, it might. Can you estimate how many megabytes per year
  68. would be required on your system to record all transactions?
  69.  
  70. Second, even though Dr. Stodolsky stresses that the contact tracing
  71. operation would alert a system to the "possibility" of an agent's
  72. presence, does this represent a significant improvement over other
  73. more conventional means to broadcast alerts of a potential problem, as
  74. is now done over the Internet?
  75.  
  76. - -----> It represents a better way of reacting to alerts.
  77. Current alerts require human intervention at every system on the net each
  78. time an alert is transmitted. A Net Hormones Receptor Program would filter
  79. out most alerts automatically. The key question here is whether this would
  80. actually reduce the work load of an computer emergency response team.
  81. Current methods might also be too slow in an epidemic.
  82.  
  83. For example, if I were running a BSD
  84. version of UNIX last November, the tcp-ip broadcast alert--assuming
  85. the gateways were still up and functioning--might have been adequate
  86. to respond to the Internet Worm.  If "contact tracing" had been
  87. available, however, would not non-BSD UNIX systems have received
  88. "alerts" which would have caused unnecessary concern?
  89.  
  90. - -----> The fact that non-BSD systems were not at risk was only
  91. discovered later. If these systems did not receive the tcp-ip
  92. broadcast alert and they had been at risk of infection, then they
  93. would really have been in a bad position. With Net Hormones in
  94. operation, each system at risk would broadcast an non-specific alert,
  95. initially. This might show some pattern of machine or software type.
  96. For instance, with the Internet Worm, there was a sudden large
  97. increase in transactions between BSD machines particularly in the Bay
  98. Area where there is a wide-band network. If this was a substantial
  99. portion of the normal traffic, it could give crucial clues as to what
  100. systems were at risk. In any case, later reports of confirmed
  101. infections would follow. If I were operating a non-BSD system, and
  102. dozens of BSD systems reported infections and not one non-BSD system
  103. had reported an infection, I certainly would begin to think I had
  104. nothing to worry about.  What this shows is that some kind of
  105. statistical estimation procedure might be built into the Net Hormones
  106. Receptor Program to avoid unnecessary alarms.
  107.  
  108.  
  109. Third, if the alert through contact tracing is to "restrict further
  110. transmission of the agent," is not cutting off communications among
  111. hosts on a network the only practical solution pending further
  112. investigation?
  113.  
  114. - -----> No, at least it is not obvious. Cutting off communication among
  115. hosts may isolate them from information needed to combat the infection and
  116. prevent further investigation from being effective. If a system was already
  117. infected, then cutting off communication might lead to reinfection of the
  118. net when that system came back on-line. The agent might have already spread
  119. to removable media, such as disks and tapes at that site. A disinfection
  120. program, most easily obtained over the net, would no doubt be needed in
  121. such a case. Asking hundreds, thousands, or millions of systems to stay off
  122. the net until a program is delivered off-line is not practical. Even
  123. arranging transfers of a program over the net by voice telephone, so one
  124. could be sure it was not an infectious agent, seems like an impractical
  125. task, given a large number of systems.
  126.  
  127. - -----> Also, the sole objective of the infection might be to bring the
  128. net down. Some intermediate response is desirable. In the great New
  129. York power black-out, operators did not drop their connections even
  130. though the conditions indicated that this was appropriate. The
  131. consequences of dropping off the net were considered to be so great
  132. that operators were not really given the discretion to drop their
  133. network connections. Stodolsky (1989a) did suggest the possibility of
  134. dropping off the net momentarily to disrupt ongoing transfers and take
  135. essential precautions.
  136.  
  137. - -----> If we had, for example, virus like programs that were likely to
  138. destroy worms, we might release them as a programmed reaction to an
  139. alert, while staying on the net to received new information, such as,
  140. that it is a non-BSD worm. The use of benign virii that could
  141. deactivate an invading agent has been suggested (Stodolsky, 1989b).
  142. Others (Odawa, 1989; Platt, 1989a; Youngman, 1989), however, have
  143. objected that no virus is really benign and it would likely cause
  144. damage in some machine - software configuration. Even if we assume
  145. this is true, such benign agents might be temporarily activated, when
  146. there was a risk of major damage from an yet unidentified infectious
  147. agent. Platt (1989b), on the other hand, suggests that custom virii
  148. could be effectively controlled. Certainly a disinfection program that
  149. eventually would be distributed to eliminate the new agent could also
  150. be programmed to clean up any remaining parasitic virii, antibodies,
  151. killer T-cells, or whatever, released during an alert.
  152.  
  153.  
  154. Chris McDonald
  155. White Sands Missile Range
  156.  
  157.  
  158. - -----> References
  159.  
  160. McDonald, C. (1989, April 28). Net Hormones paper by David S. Stodolsky.
  161. VIRUS-L Digest, 2(102).
  162.  
  163. Odawa, M. (1989, May 4). "Benign" Viruses. In Usenet Comp.Virus Conference
  164. (Virus-L Digest,  2[107]).
  165.  
  166. Odawa, M. (1989, May 12). The only good virus is a dead one. Virus-L
  167. Digest,  2(113).
  168.  
  169. Platt, D. (1989a, May 8). "Benign" Viruses. Virus-L Digest , 2(110).
  170.  
  171. Platt, D. (1989b, May 10). Biological analogues. Virus-L Digest , 2(112).
  172.  
  173. Stodolsky, D. (1989a). Net hormones: Part 1 - Infection control assuming
  174. cooperation among computers [Machine-readable file]. Van Wyk, K. R. (1989,
  175. March 30). Several reports available via anonymous FTP. Virus-L Digest,
  176. 2(77, Article 1). Abstract republished in van Wyk, K. R. (1989, April 24).
  177. Virus papers (finally) available on Lehigh LISTSERV. Virus-L Digest, 2(98,
  178. Article 4). (Available via anonymous file transfer protocol from LLL-
  179. WINKEN.LLNL.GOV; File name "~ftp/virus-l/docs/net.hormones": Lawrence
  180. Livermore National Laboratory, Nuclear Chemistry Division and
  181. IBM1.CC.LEHIGH.EDU; File name "HORMONES NET": Lehigh University. And by
  182. electronic mail from LISTSERV@LEHIIBM1.BITNET; File name "HORMONES NET":
  183. Lehigh University).
  184.  
  185. Stodolsky, D. (1989b, May 4). Virus - worm combinations: A future trend?
  186. Virus-L Digest, 2(105).
  187.  
  188. Youngman, N. (1989, May 16). Re: The only good virus is a dead one. Virus-L
  189. Digest, 2(117).
  190.  
  191. Youngman, N. (1989, May 18). Re: The only good virus is a dead one. Virus-L
  192. Digest, 2(119).
  193.  
  194. - ----->
  195. - --
  196. David S. Stodolsky, PhD      Routing: <@uunet.uu.net:stodol@diku.dk>
  197. Department of Psychology                  Internet: <stodol@diku.dk>
  198. Copenhagen Univ., Njalsg. 88                  Voice + 45 31 58 48 86
  199. DK-2300 Copenhagen S, Denmark                  Fax. + 45 31 54 32 11
  200.  
  201. ------------------------------
  202.  
  203. Date:    Mon,  12 Jun 89 15:02:23 +0300
  204. From:    Y. Radai <RADAI1@HBUNOS.BITNET>
  205. Subject: Re: naming confusion
  206.  
  207.   Robert Morey writes (#133):
  208.  
  209. >  Regarding the "PLO" virus and your suggestion that we not call it by
  210. >that name, don't you think that your desire to suppress the link
  211. >between the virus and something which obviously offends you (the name
  212. >"PLO") is a political tactic?
  213.  
  214.   It's unfortunate that Mr. Morey has read a political motive into my
  215. remarks.  His claims that I'm "obviously offended" by the name "PLO"
  216. and that I'm trying to "suppress" something are products of his
  217. imagination alone and have no basis in reality.  My reason for being
  218. opposed to labelling the Israeli virus the "PLO" virus is precisely
  219. the same reason that I am opposed to labelling it the "DAR" virus, the
  220. "Mongolian" virus or the "Einstein" virus: These names are simply
  221. INAPPROPRIATE.  That's really all there is to it, Mr. Morey.  Of
  222. course, no one can prevent your imagination from concocting other
  223. motivations.  But you have no right to accuse people of them without
  224. evidence, which you certainly don't have in my case since your claims
  225. are false.
  226.  
  227. >                               That particular virus is known to many
  228. >people already as the "PLO virus"--now you expect them to have to
  229. >worry about changing that name in their minds because it offends
  230. >someone?
  231.  
  232.   Is changing a name really such a hardship for you?  Suppose it
  233. turned out that the story about the Brain virus originating in
  234. Pakistan was merely a rumor, spread by someone with a hyperactive
  235. imagination, that it really originated in Timbuctoo, and never even
  236. spread to Pakistan.  And suppose on that basis someone in Pakistan
  237. asked us to stop referring to it as the Pakistani virus.  I would
  238. comply immediately.  No problem, no "worry".  Are you so inflexible
  239. that you can't do the same in the case of the so-called "PLO" virus??
  240. If you're offended by the name "Israeli", you can call it the "Friday-
  241. 13" virus, the "Little Black Box", or any of about 8 other reasonable
  242. names.  Btw, suppose that someone started calling the Israeli virus
  243. the "Morey" virus and that this name caught on.  Wouldn't you feel
  244. like asking people to stop using this name?  I wonder if you'd be
  245. quite so sympathetic in that case to the plight of people having to
  246. alter their habits simply "because it offends someone" ....
  247.  
  248.   If you wish to continue this discussion, fine.  But if it's anything
  249. more than a one-sentence apology for attributing false motives to me,
  250. mail your remarks to me personally.  VIRUS-L is not a forum for poli-
  251. tics or slanders.
  252.  
  253.                                           Y. Radai
  254.                                           Hebrew Univ. of Jerusalem
  255.  
  256.   P.S.  On another subject:  In Issue 116 (May 16) I posted a list of
  257. 20 PC viruses and asked if anyone has comments to send them to me
  258. personally.  It turns out that precisely at that time we had mailer
  259. problems and a lot of mail which was addressed to me didn't reach me.
  260. So if anyone sent me mail and didn't receive a reply, please re-send.
  261.  
  262. ------------------------------
  263.  
  264. Date:    Mon, 12 Jun 89 15:07 EDT
  265. From:    Roman Olynyk - Information Services <CC011054@WVNVAXA.WVNET.EDU>
  266. Subject: RE: software industry vs. viruses
  267.  
  268. My unguarded comment about the hidden text in Microsoft Word Version
  269. 1.0 was not intended to be an indictment of the software industry.
  270. This copy is more than six years old, and six years in this industry
  271. is too long to hold any sort of grudge.  I regarded this as more of a
  272. curiosity, something for your amusement.  To set the facts straight,
  273. however, the statement exists in Word V1.0 for the PC -- at least this
  274. is the version I'm talking about -- not the Mac.  The disk that I have
  275. is an *original* of the system disk -- Microsoft Registration No.
  276. 301786.  The "Trashing program disk" text appears in the file
  277. WORD.COM, disk sector 171, offset 256.
  278.  
  279. I'm glad that the spokesmen for the software industry are so rabid in
  280. its defense.  I'm sure that the American Medical Association, the Bar
  281. Association and any other group is equally as rabid in defense of its
  282. profession.  That's fine -- professional organizations should take
  283. such stands.  However, let's not get carried away and say that these
  284. things (viruses in commercial software) cannot happen or that
  285. renegades don't exist.  They do.  So the CEO disavows any knowledge of
  286. such action.  There doesn't have to be a conspiracy to sue for
  287. damages.  Therefore, I think it's good that the software industry
  288. tries to police itself.  I think they should throw the book at and
  289. keel-haul anyone attempting to tamper with legitimate software.
  290.  
  291. ------------------------------
  292.  
  293. End of VIRUS-L Digest
  294. *********************
  295.  
  296.  
  297. Downloaded From P-80 International Information Systems 304-744-2253
  298.