home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.266 < prev    next >
Text File  |  1995-01-03  |  26KB  |  581 lines
  1. VIRUS-L Digest   Thursday, 21 Dec 1989    Volume 2 : Issue 266
  2.  
  3. VIRUS-L is a moderated, digested mail forum for discussing computer
  4. virus issues; comp.virus is a non-digested Usenet counterpart.
  5. Discussions are not limited to any one hardware/software platform -
  6. diversity is welcomed.  Contributions should be relevant, concise,
  7. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  8. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  9. anti-virus, document, and back-issue archives is distributed
  10. periodically on the list.  Administrative mail (comments, suggestions,
  11. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  12.  - Ken van Wyk
  13.  
  14. Today's Topics:
  15.  
  16. AIDS Fix - phone no.
  17. Trojan AIDS: the AIDS program (PC)
  18. Re: AIDS disk (PC)
  19. AIDS Information Disk Technical Analysis available
  20. Re: Gatekeeper and Gatekeeper Aid (Mac)
  21. Holiday VIRUS-L/comp.virus interruption
  22. Authentication
  23. Invisible INITs - Don't (Mac)
  24. Re: Gatekeeper and Gatekeeper Aid (Mac)
  25. Artificial Life Workshop - final announcement!
  26. Another AIDS disk recipient (PC)
  27. Flu virus (PC)
  28.  
  29. ---------------------------------------------------------------------------
  30.  
  31. Date:    20 Dec 89 17:07:18 +0000
  32. From:    G.Toal@edinburgh.ac.uk
  33. Subject: AIDS Fix - phone no.
  34.  
  35. The following has been sent to me for forwarding.  The AIDS disk that my
  36. colleague received was 2.00 and arrived when all the others did.  I have
  37. no other information about the AIDS Version 1.0 diskette.
  38.  
  39. Sam Wilson
  40. Network Planning, Edinburgh University Computing Service
  41.  
  42. - --- Forwarded message:
  43.  
  44. Subject:  AIDS Fix - phone no.
  45. From:     G.Toal @ uk.ac.edinburgh
  46. Date:     20 Dec 89  16:00:54 gmt
  47.  
  48. >From Frank J Leonhardt. fjl@cix aka uab1018@dircon.UUCP
  49.  
  50. Here is some information about the Aids disc, gleaned from research
  51. done in London, which, judging from messages taken from the network
  52. and passed on to me from the Edinburgh Virus BB, you may not be aware of.
  53.  
  54. There are indeed two versions of the disc. There were a few, sent out
  55. about a month ago, labelled as version 1.0. Most of them are labelled
  56. 2.0. The two versions are different.
  57.  
  58. There is a complete fix program available, which will totally un-
  59. scramble you disc even if the trojan has done it's stuff. Not easy
  60. when you consider how the encryption key was made up (i.e. out of free
  61. memory, date, MS-DOS version and so on). If you need this program you
  62. can get hold of it by 'phoning 01-831 9252 (PCBW offices) and ask for
  63. it. PCBW can also be found in the basement of 99 Grey's Inn Road,
  64. London, and would love some more copies of the discs, especially
  65. version 1.0.
  66.  
  67. The program to restore a smashed disc is called CLEARAIDS and will
  68. soon be available on "cix" in the conference "virus/files". CIX is a
  69. commercial system which us poor non-academics have to use instead of
  70. Janet. <hint!> [OK Frank - I'll get you an ID. GToal]
  71.  
  72. Thanks for gtoal@uk.ac.ed for getting stuff on and off Janet for this.
  73.  
  74. Frank J Leonhardt. fjl@cix aka uab1018@dircon.UUCP
  75.  
  76. - --- End of forwarded message
  77.  
  78. ------------------------------
  79.  
  80. Date:    20 Dec 89 16:36:00 +0100
  81. From:    Klaus Brunnstein <brunnstein@rz.informatik.uni-hamburg.dbp.de>
  82. Subject: Trojan AIDS: the AIDS program (PC)
  83.  
  84. The AIDS diskette contains 2 programs,
  85.               INSTALL.EXE   146.188 Bytes   9-28-89     4:28p
  86.               AIDS.   EXE   172.562 Bytes   8-07-89    10:28p
  87.  
  88. the first of which is described by J.McAfee and others (INSTALL.EXE and it's
  89. installed versions REM,SHARE) in VIRUS-L; this is the Trojan horse.
  90.  
  91. The AIDS-program itself contains a question/answering session with AIDS-
  92. related question, where a `risk' (on 7 levels) is computed for the specific
  93. answers. While most other groups are analysing the INSTALLed Trojan horse,
  94. one group at Virus Test Center Hamburg actually analyses the AIDS program.
  95.  
  96. We have run several sessions, and we regard the program as *not very
  97. intelligent* from the Informatics standpoint, and *not highly reliable*
  98. from the medical standpoint (we will prove this with some medical experts; we
  99. received 4 copies from specialists in immunology, and 3 more copies from
  100. banks etc).
  101.  
  102. The AIDS program works rather linearly; the dialogue is done with simple
  103. multiple choices, where the 1st option is alwys HELP-text. If you analyse the
  104. HELP texts, they are not very specific (many of them may have been generated
  105. from an ordinary lexikon). In section 1, BACKGROUND INFORMATION is gathered,
  106. e.g. residence country, sex, age (in 9 clusters), ancestors origin continent,
  107. sexual behaviour (heterosexual, no sexual experience, homosexual or bisexual),
  108. and number of sex partners since 1980 (in 8 clusters from 0 to 100+)are asked.
  109.  
  110. In section 2, MEDICAL HISTORY is examined, e.g. how many blood transfusions
  111. since 1980, active tuberculosis, drug injection, sexually transmitted
  112. diseases, sexual habits (use of condom..). For some positive answers,
  113. there may be additional details asked for. No mechanism is visible whcih
  114. safeguards the extensive personal data; on the other side, no data are
  115. gathered which may be used to authenticate a person and relate their name
  116. with the data gathered.
  117.  
  118. After an evaluation procedure (less than 1 minute on an AT), `you' are
  119. assigned to one of seven Levels of AIDS Risk (`no risk, very low risk,
  120. low risk, medium risk, high risk, very high risk, extremely high risk).
  121. Depending on the list of answers, a PERSONAL ADVICE is given, e.g. stating
  122. `Your risk of exposure to the AIDS virus is low but presently increasing..',
  123. suggesting to use condoms, etc. Finally, you are asked to input YOUR
  124. COMMENTS (`Use the computer like a typewriter. Type anything that comes to
  125. your mind ... The computer will then analyze your remarks and respond to you
  126. with further comments..'). The answers are rather unspecific.
  127.  
  128. Based on some experiments (with more systematic testing to be done
  129. after having reverse-engineered the code), my best estimation is, that
  130. the question-answering is done in typical BASIC style, and that the
  131. risk evaluation function is only very rudimentary (we received a 'low
  132. risk' for a young female drug addict). The personal advice seems to be
  133. programmed from a few types of answers, and the analysis of Your
  134. Comments fails with even simple, AIDS-related questions.
  135.  
  136. The 'loose' relation between INSTALL/REM/SHARE and AIDS (probably influencing
  137. the catastrophic counter, evidently initialised at 90 and decremented during
  138. bootup) will very probably allow to use the INSTALL process also *in connection
  139. with other 'interesting programs'*. With so may diskettes distributed, we may
  140. face similar (and maybe more serious) threats. I therefore appreciate
  141. J.McAfee's remark that he has included his ANTI-Trojan in his ANTIVIRUS tool.
  142. Though mixing up an Antivirus Tool with Anti-Trojan functions may produce
  143. new problems (e.g. misunderstanding the respective threats and the limitations
  144. of such tools), I suggest that also other antivirus tools should contain a
  145. diagnostic featrue for Trojan AIDS.
  146.  
  147. Evaluating the given situation, I conclude that the business procedure (the
  148. e.g. distribution of diskettes) was professional, and that the Trojan horses
  149. mechanisms were rather intelligent, though some parts of the INSTALL/REM/SHARE
  150. are primitively linear programmed, e.g. the `encryption' part. The AIDS
  151. program is of neither good programming nor medical standard.
  152.  
  153. Klaus Brunnstein
  154. - -----------------------------------------------------------------------
  155. PostAdress:      Prof.Dr. Klaus Brunnstein
  156.             Faculty for Informatics, Univ.Hamburg
  157.                     Schlueterstr.70
  158.                    D 2000 Hamburg 13
  159.            Tel: (40) 4123-4158 / -4162 Secr.
  160. ElMailAdr:   Brunnstein@RZ.Informatik.Uni-Hamburg.dbp.de
  161. FromINTERNET:Brunnstein%RZ.Informatik.Uni-Hamburg.dbp.de@Relay.CS.Net
  162. FromBITNET:  Brunnstein%RZ.Informatik.Uni-Hamburg.dbp.de@DFNGate.Bitnet
  163. FromUUCP:    brunnstein%rz.informatik.uni-hamburg.dbp.de@unido.uucp
  164. - -----------------------------------------------------------------------
  165.  
  166. ------------------------------
  167.  
  168. Date:    Wed, 20 Dec 89 18:33:56 +0000
  169. From:    Phil OKunewick <okunewck@psuvax1.cs.psu.edu>
  170. Subject: Re: AIDS disk (PC)
  171.  
  172. attcan!ram@uunet.UU.NET (Richard Meesters) writes:
  173. >martin@EASBY.DURHAM.AC.UK (Martin Ward) writes:
  174. >> I feel that I should point out that the effects of this disk are
  175. >> entirely in accordance with the standard warrenty used by most
  176. >> commercial software developers...
  177. >
  178. >...Warranty implies that the
  179. >product was purchased and you are following the terms of the purchase
  180. >agreement.  The trojan runs for a time and then demands that you pay
  181. >for the product...
  182. >  ...kidnaps your data and holds it for ransom.
  183. >
  184. >Illegal, or at least extremely Immoral (presumably the former).
  185.  
  186.     Illegal in the United States, which may be why they didn't try to
  187. spread it here.
  188.  
  189.     According to the regulations of the U.S. Postal Service, if you
  190. receive something through the mail which you have not ordered, then
  191. you automatically own it.
  192.  
  193.     If this were not enforced, then many of these annoying organizations
  194. that send us ads for junk products would instead be sending us the junk
  195. products, along with a bill for their trash.
  196.  
  197.     Does the U.K. have a similar law?
  198. - --
  199.                                         ---Phil
  200. (erutangis. ruoy naht daer ot redrah si erutangis. yM)
  201.  
  202. ------------------------------
  203.  
  204. Date:    Mon, 18 Dec 89 11:14:02 +0000
  205. From:    Alan Jay <alanj@IBMPCUG.CO.UK>
  206. Subject: AIDS Information Disk Technical Analysis available
  207.  
  208. The following Article was submitted by Alan Solomon for distribution
  209. on CONNECT and USENET.  It relates to the AIDS Information Disk and
  210. gives extensive technical details of the disk and the AIDS program.
  211.  
  212. This article is 1800 lines long.
  213.  
  214. Dr Alan Solomon is Chairman of the IBM PC User Group, London.
  215.  
  216.  
  217. Alan Jay -- The IBM PC User Group -- PO Box 360, HARROW HA1 4LQ -- 01-863 1191
  218.  
  219. [Ed. Due to its length, the document has been forwarded to the
  220. comp.virus documentation archive sites.]
  221.  
  222.  
  223. ------------------------------
  224.  
  225. Date:    Wed, 20 Dec 89 16:30:16 -0500
  226. From:    dmg%retina.mitre.org@IBM1.CC.Lehigh.Edu (David Gursky)
  227. Subject: Re: Gatekeeper and Gatekeeper Aid (Mac)
  228.  
  229. In VIRUS-L Digest V2 #265, "Carl_A.Fassbender" <YOOPER@MSU.BITNET> was
  230. asking why the Gatekeeper & Gatekeeper Aid icon did not show up after
  231. he made the files invisible.
  232.  
  233. The Mac OS does not load INITs that are part of files with the
  234. Invisible bit set.  [Editorial comment: Hey Apple!  Why?????]  If you
  235. want to have Gatekeeper active, you must have the file visible on the
  236. desktop.
  237.  
  238. ------------------------------
  239.  
  240. Date:    Wed, 20 Dec 89 16:26:53 -0500
  241. From:    Kenneth R. van Wyk <krvw@SEI.CMU.EDU>
  242. Subject: Holiday VIRUS-L/comp.virus interruption
  243.  
  244. With the Holiday season approaching, VIRUS-L/comp.virus will be rather
  245. intermittent during the next week.  I will be in the office until
  246. Friday, December 22 and out for the entire next week.  However, I will
  247. be logging in from home periodically and sending out the occasional
  248. digest (as demand dictates).
  249.  
  250. Remember that urgent messages, as always, can be sent to
  251. VALERT-L@IBM1.CC.LEHIGH.EDU.  Please do not use VALERT-L for
  252. discussion - VALERT-L was created due to requests from people who wish
  253. to keep up with virus activity only, not discussions.  All followup
  254. and subsequent discussions should be sent to VIRUS-L/comp.virus.
  255.  
  256. Also, the Computer Emergency Response Team (CERT) can be reached via
  257. email (monitored daily) at cert@sei.cmu.edu or (for more urgent
  258. problems) at 24 hours a day at (412) 268-7090 for Internet related
  259. security incidents.
  260.  
  261. Holiday Cheers and Best Wishes to all!
  262.  
  263. Ken
  264.  
  265. Kenneth R. van Wyk
  266. Moderator VIRUS-L/comp.virus
  267. Technical Coordinator, Computer Emergency Response Team
  268. Software Engineering Institute
  269. Carnegie Mellon University
  270. krvw@SEI.CMU.EDU
  271. (412) 268-7090  (24 hour hotline)
  272.  
  273. ------------------------------
  274.  
  275. Date:    Wed, 20 Dec 00 19:89:52 +0000
  276. From:    greenber@utoday.UU.NET (Ross M. Greenberg)
  277. Subject: Authentication
  278.  
  279. Bob Bosen, of Enigma, comments in VL V2#265 further about the need for
  280. X9.9 as the level of sophistication required of an authentication
  281. scheme.
  282.  
  283. I'm not sure he's right.  Let's look at two different usages for
  284. authentication schemes: one, to determine if a program is what you
  285. expect it to be during a "global" scan, one to determine if the
  286. program is what you expect it to be immediately before it is run.
  287.  
  288. A subset of the second portion above is whether a program can contain
  289. a self-checker -- a portion that checks itself when it is run.  I
  290. propose that self-checkers, while useful, are meaningless: by the time
  291. a self-checker's checking code is run, the virus or trojan's damage is
  292. already done.  Additionally, what prevents the virus/trojan from
  293. removing itself from the host file and/or memory before the
  294. self-checker runs?  Therefore, self-checking programs are not realy
  295. worthy of further comment.
  296.  
  297. Case 1, above, when a scanning program checks a file's signature
  298. against a supposed signature is good stuff.  Yet, you must prepare
  299. yourself for a long initial time to build the original authentication
  300. database -- the more complex the scheme, the longer such a check will
  301. take.  There's a commercial anti-virus program out there already that
  302. does some sort of authentication check on every executable on your
  303. disk (PC-based).  On a full disk, it can take something like three
  304. hours to run on an XT machine.  X9.9 might be a good approach, but if
  305. it takes even that longer and not longer, you simply won;t get people
  306. using it -- regardless of how wonderful it is.  If I have to run such
  307. a beast each morning, I'll pass.  I think most commercial users would
  308. bypass a long wait -- they do, after all, have some work to do.
  309.  
  310. What about a checker that checks only that a file you're about to run
  311. is what you expect, then?  This *may* be worthy of comment (heck, my
  312. own code does that! :-) ), but it depends on how long it takes.  If it
  313. takes me ten minutes to load Word Perfect on my trusty 4.77MHz, run
  314. asophisticated authentication check against it and then finally get to
  315. run it, well, my boss is not going to be too happy. So, the more
  316. sophisticated the algorithm, the less likely it is to be used.  I know
  317. this from my own beta testers for a new release of my own product:
  318. they felt that the more sophisticated checker, although nice and more
  319. trustworthy, simply took too long to run.  Given a choice, and they
  320. make their choices known with their payments, they opt for one that's
  321. "good enough".
  322.  
  323. What's a programmer to do, then?  My suggestion is easy: forget those
  324. who claim that sophisticated checkers are what we need -- they may be
  325. right, but there are many drawbacks to them, and we all still have
  326. work to do!  Forget those who claim that their solution is the only
  327. solution.  But, I'd rather have two unrelated and unsophisticated
  328. algorithms that the "bad guy" knows nothing about, then one
  329. "unbeatable" algorithm that goes unused.
  330.  
  331. Since there are umpteen different ways that such checkers could be
  332. written, the odds of two such routines generating the same results
  333. given a change in the source is pretty darned small.  And, if you're
  334. still in doubt, then run a third or forth or 20th checker.....
  335.  
  336. Ross M. Greenberg
  337.  
  338. Ross M. Greenberg, Technology Editor, UNIX Today!   greenber@utoday.UUCP
  339.              594 Third Avenue, New York, New York, 10016
  340.  Voice:(212)-889-6431 BIX: greenber  MCI: greenber   CIS: 72461,3212
  341.   To subscribe, send mail to circ@utoday.UUCP with "Subject: Request"
  342.  
  343. ------------------------------
  344.  
  345. Date:    Wed, 20 Dec 89 16:51:15 -0500
  346. From:    Joe McMahon <XRJDM@SCFVM.BITNET>
  347. Subject: Invisible INITs - Don't (Mac)
  348.  
  349. Any file which is invisible will not bec checked for INIT resources.
  350. This means that GateKeeper and GateKeeper Aid are *not working*
  351. because they have not gotten to install their hooks.
  352.  
  353. System 6.0.2 (I think) was the first System to add this check to the INIT
  354. mechanism; this was done to help combat the Scores virus's famous invisible
  355. "Desktop" and "Scores" files, which contained INITs.
  356.  
  357. Summary: Make INITs and cdev's invisible, and any INITs they install won't
  358.          work.
  359.  
  360.  --- Joe M.
  361.  
  362. ------------------------------
  363.  
  364. Date:    20 Dec 89 22:34:09 +0000
  365. From:    coherent!dplatt@ames.arc.nasa.gov (Dave Platt)
  366. Subject: Re: Gatekeeper and Gatekeeper Aid (Mac)
  367.  
  368. YOOPER@MSU.BITNET (Carl_A.Fassbender) writes:
  369. > In Michigan State University's public laboratory, we have run into
  370. > many viruses including the WDEF virus.  We decided to put Gatekeeper
  371. > and Gatekeeper aid on our system disks.  To protect these files from
  372. > being erased, they were made invisible using MacTools.  Now in the
  373. > control panel, the Gatekeeper icon does not show up.  Question: Does
  374. > this mean that Gatekeeper is not active?  What about Gatekeeper Aid?
  375.  
  376. Apple's System 6.0 and later will not execute INIT resources which reside
  377. in invisible files.  This was done to prevent viruses (e.g. SCORES)
  378. from dropping invisible INIT files into the System folder.  By making
  379. the Gatekeeper and Gatekeeper Aid files invisible, you've rendered them
  380. inoperative.
  381.  
  382. You can, if you wish, make the whole System folder invisible;  this won't
  383. prevent the system from booting and won't prevent Gatekeeper etc. from
  384. installing themselves.  For lab machines, this is often a reasonable
  385. approach.
  386. - --
  387. Dave Platt                                             VOICE: (415) 493-8805
  388.   UUCP: ...!{ames,apple,uunet}!coherent!dplatt   DOMAIN: dplatt@coherent.com
  389.   INTERNET:       coherent!dplatt@ames.arpa,  ...@uunet.uu.net
  390.   USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303
  391.  
  392. ------------------------------
  393.  
  394. Date:    20 Dec 89 22:29:59 +0000
  395. From:    cgl@lanl.gov (C G Langton)
  396. Subject: Artificial Life Workshop - final announcement!
  397.  
  398.  FINAL ANNOUNCEMENT !!!!
  399.  
  400.                             ARTIFICIAL LIFE
  401.                             ---------------
  402.  
  403.                      A workshop on the synthesis of
  404.                      living and evolving artifacts.
  405.  
  406.  
  407.                           February 5-9, 1990
  408.                          Santa Fe, New Mexico
  409.  
  410.                              Sponsored by
  411.                              ------------
  412.  
  413.                 The Center for Nonlinear Studies, LANL
  414.                                   and
  415.                         The Santa Fe Institute
  416.  
  417.  
  418.  
  419.                             Self-Organizers
  420.                             ---------------
  421.  
  422.                               Doyne Farmer
  423.                              Chris Langton
  424.                             Steen Rasmussen
  425.                              Charles Taylor
  426.  
  427.    Artificial Life has only recently emerged as a coherent field of
  428.    scientific research. Its primary methodological approach is to study
  429.    life and evolution by attempting to actually create living and/or
  430.    evolving processes within computers, beakers, or other ``artificial''
  431.    media. Its primary goal is to abstract the ``logical form'' of life
  432.    from its material basis - and to construct a truly general theory of
  433.    living systems, one which will be capable of treating life wherever it
  434.    is found in the universe and whatever it is made of. ``Artificial'' Life
  435.    can contribute to the study of ``real'' life by helping to locate
  436.    life-as-we-know-it within the larger context of life-as-it-could-be,
  437.    in any of its possible incarnations.
  438.  
  439.    This will be the second workshop on the topic of Artificial Life. The
  440.    workshop will include invited and contributed talks, demonstrations,
  441.    and discussions on the many scientific, technical, philosophical, and
  442.    moral issues surrounding the increasing attempts to synthesize life
  443.    artificially. We will also have an artificial ``4H show'' with prizes
  444.    for the best artificial life-forms.
  445.  
  446.    Specific investigations in the field of Artificial Life include attempts
  447.    to synthesize, simulate, or otherwise recreate the following:
  448.  
  449.    - the emergence of autocatalytic sets within soups of artificial polymers;
  450.  
  451.    - the evolution of strings of code using Genetic Algorithms;
  452.  
  453.    - self-reproducing bit-strings, clay-crystals, RNA molecules, or LEGO-robots
  454. ;
  455.  
  456.    - the emergence of cooperativity, colonial organization, multi-cellularity,
  457.        and hierarchical organization;
  458.  
  459.    - the embryological processes of growth, development, and differentiation;
  460.  
  461.    - the emergence of social behavior in populations of artificial insects;
  462.  
  463.    - the emulation of population and ecosystem dynamics;
  464.  
  465.    - the implementation of artificial environments, logical universes,
  466.        or ``virtual realities'' sufficiently rich to support the open-ended
  467.        evolution of embedded ``organisms'';
  468.  
  469.    - cultural evolution, including the origin and evolution of socio-
  470.        cultural institutions, and the evolution of natural language in its
  471.        role as a vehicle for cultural inheritance;
  472.  
  473.    - the dynamics of self-propagating information structures such as
  474.        biological and computer viruses;
  475.  
  476.    Many of the investigations mentioned above will be reported on or
  477.    discussed at the workshop.
  478.  
  479.    We expect that there will also be plenty of debate on the question of
  480.    whether or not symbolic processes within computers can be considered
  481.    ``alive'' in principle, or whether they could be capable of participating
  482.    in anything like truly open-ended evolution. These debates will probably
  483.    parallel to a large extent the debates in the AI community on whether
  484.    processes within computers can considered to be ``intelligent'' or
  485.    ``conscious.''
  486.  
  487.    We are also encouraging presentations and/or debates on the moral and
  488.    social consequences of achieving the capability to create living things.
  489.    The mastery of the technology of life will easily overshadow any of our
  490.    previous technological accomplishments - even our mastery of the technology
  491.    of death - in terms of the burden of responsibility which it places on our
  492.    shoulders. As was the case for the mastery of atomic fission and fusion,
  493.    the potential abuses are directly proportional to the potential benefits.
  494.    Once again, we are in a position where our technical understanding of nature
  495.    is far in advance of our understanding of the potential consequences
  496.    of mastering or deploying the technology. This is not an enterprise to
  497.    be undertaken lightly, or to be pursued in the cause of such shortsighted
  498.    goals as fleeting military advantage.
  499.  
  500.    The increasing spread and sophistication of computer viruses is evidence
  501.    both of the imminence of this new era in the history of life, and of the
  502.    complexity of the problems and issues that will be facing all of us in
  503.    the not-too-distant future.
  504.  
  505.    We welcome your presence and contribution on any aspect of Artificial
  506.    Life that you consider worth presenting or discussing with others
  507.    who are interested in such issues. Whether you are a scientist, an
  508.    engineer, a philosopher, an artist, or just a concerned citizen, we
  509.    feel that ALL points of view need to be aired at this early stage in
  510.    the evolution of Artificial Life.
  511.  
  512.    For further information and/or registration materials, contact:
  513.  
  514.                              Andi Sutherland
  515.                          The Santa Fe Institute
  516.                              1120 Canyon Rd.
  517.                           Santa Fe, New Mexico
  518.                                  87501
  519.  
  520.                               505-984-8800
  521.                           andi@sfi.santafe.edu
  522.  
  523.    The deadline for contributions is Dec. 31, 1989. Registrations for
  524.    the workshop will be accepted right up to the date of the workshop.
  525.    Some limited financial assistance will be available for the truly
  526.    needy.
  527.  
  528.    The proceedings of the first Artificial Life Workshop, held at
  529.    the Center for Nonlinear Studies, Los Alamos, New Mexico in 1987,
  530.    are available from Addison Wesley: "Artificial Life: The proceedings
  531.    of an interdisciplinary workshop on the synthesis and simulation
  532.    of living systems", edited by Christopher G. Langton, Volume #6
  533.    in Addison Wesley's `Santa Fe Institute Studies in the Sciences
  534.    of Complexity' series. They can be ordered toll free by calling
  535.    800-447-2226. The order codes are:
  536.  
  537.               Hardback  (about $40) ISBN 0-201-09346-4
  538.               Paperback (about $20) ISBN 0-201-09356-1
  539.  
  540. ------------------------------
  541.  
  542. Date:    Thu, 21 Dec 89 02:36:00 +0700
  543. From:    MARCO VAN DEN BERG / IRRI <BROERS@RCL.WAU.NL>
  544. Subject: Another AIDS disk recipient (PC)
  545.  
  546.         Just to complete the picture : at our institute here in the
  547. Philippines we have so far received two copies of the AIDS disk as
  548. well, but neither of them was installed on a user's machine (thanks to
  549. the warnings from this (now) esteemed forum). Please note that it is
  550. extremely likely that many folks in international organizations (UN,
  551. World Bank, etc.) will be sent this disk when they have ever dropped a
  552. business card at some computer show.
  553.  
  554.         By the way, I *really* think the US reaction is a little
  555. overdone, I'm sure that Noriega doesn't even know a keyboard from an
  556. M16...
  557.  
  558. Marco van den Berg
  559. International Rice Research Institute
  560. Los Banos
  561. The Philippines
  562. CGI402%NSFMAIL@INTERMAIL.ISI.EDU or BROERS@RCL.WAU.NL
  563.  
  564. ------------------------------
  565.  
  566. Date:    Thu, 21 Dec 89 10:46:26 +0000
  567. From:    frisk@rhi.hi.is (Fridrik Skulason)
  568. Subject: Flu virus (PC)
  569.  
  570. I just received a message from Australia, describing "Flu", a new
  571. virus, that uses a good deal of self-modifying code. Does anyone have
  572. more information ?
  573.  
  574. - -frisk
  575.  
  576. ------------------------------
  577.  
  578. End of VIRUS-L Digest
  579. *********************
  580. Downloaded From P-80 International Information Systems 304-744-2253
  581.