home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl3 / virusl3.25 < prev    next >
Text File  |  1995-01-03  |  31KB  |  742 lines

  1. VIRUS-L Digest   Tuesday, 30 Jan 1990    Volume 3 : Issue 25
  2.  
  3. Today's Topics:
  4.  
  5. PC Magazine Free Utility: PCDATA (PC)
  6. ADAPSO Virus Book
  7. Security and Internet Worms (Source Code)
  8. Article on Cliff Stoll
  9. Did Morris try to stop the worm?
  10. Yet Another WDEF Infection (Mac)
  11. VAX Virus request and UMNEWS (general)
  12. Yankee Doodle Virus
  13. Prophylactic anti-viral suggestion
  14. Possible new virus?? NUCLEUR WAR.
  15. Universal virus detectors
  16. Re: Virus request
  17. Re: Virus request
  18. Re: WDEF at University of Rochester (Mac)
  19. re: 'Virus request' from Taiwan
  20. WDEF Infection (Mac)
  21.  
  22. VIRUS-L is a moderated, digested mail forum for discussing computer
  23. virus issues; comp.virus is a non-digested Usenet counterpart.
  24. Discussions are not limited to any one hardware/software platform -
  25. diversity is welcomed.  Contributions should be relevant, concise,
  26. polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
  27. LEHIIBM1.BITNET for BITNET folks).  Information on accessing
  28. anti-virus, document, and back-issue archives is distributed
  29. periodically on the list.  Administrative mail (comments, suggestions,
  30. and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
  31.  - Ken van Wyk
  32.  
  33. ---------------------------------------------------------------------------
  34.  
  35. Date:    25 Jan 90 11:53:00 -0500
  36. From:    "zmudzinski, thomas" <zmudzinskit@imo-uvax.arpa>
  37. Subject: PC Magazine Free Utility: PCDATA (PC)
  38.  
  39. PC Magazine, Vol 9 No 3, February 13, 1990, pp. 263-283, contains an
  40. article by Wolfgang Stiller, "Protect Your Data with PCDATA, the Data
  41. Integrity Toolkit".  Stiller has put together an impressive array of
  42. eight (8) programs and nineteen (19) BAT files designed "to detect and
  43. recover from all data integrity threats, including viruses".  This
  44. toolkit is available "free" (i.e. no-fee bannerware) from "PC MagNet"
  45. on CompuServe.  (Buy the magazine to get the documentation.)
  46.  
  47. Would one or more of our virus gurus please download these utilities
  48. and try them out?  I'm sure we'd all like to know how these stand up
  49. to various viruses.
  50.  
  51. /s/ Tom Zmudzinski                      Standard Disclaimer:
  52.     DCS Data Systems                   "Shill for these people?
  53.     McLean, Virginia                    Heck, I don't even know them!"
  54.  
  55. TomZ @ IMO-UVAX.DCA.MIL
  56.  
  57. ------------------------------
  58.  
  59. Date:    Mon, 29 Jan 90 10:58:50 -0500
  60. From:    Gene Spafford <spaf@cs.purdue.edu>
  61. Subject: ADAPSO Virus Book
  62.  
  63. "Computer Viruses: Dealing with Electronic Vandalism and Programmed
  64. Threats" by Eugene Spafford, Kathleen Heaphy, and David Ferbrache.
  65. 1989, 109 pages.  Published by ADAPSO.
  66.  
  67. The book has been written to be an accessible resource guide for
  68. computer users and managers (PC and mainframe).  It presents a
  69. high-level discussion of computer viruses, explaining how they work,
  70. who writes them, and what they do.  It is not intended to serve as a
  71. technical reference on viruses, both because the audience for such a
  72. work would be limited, and because such a reference might serve to aid
  73. potential virus authors.
  74.  
  75. The goal of the book is to dispell some common myths about viruses
  76. (and worms, trojan horses, et. al.), and provide simple, effective
  77. suggestions for how to protect computer systems against these threats.
  78. It furthermore stresses that most systems face greater threats from
  79. other areas, so the proper attitude to take is to strengthen overall
  80. security; concrete suggestions for enhancing overall security are also
  81. presented.
  82.  
  83. The appendices provide extensive references to other publications,
  84. security organizations, anti-viral software sources, applicable (U.S.)
  85. state and Federal laws against computer crime, and detailed
  86. descriptions of all IBM and Apple Macintosh viruses known as of 1
  87. October 1990.
  88.  
  89. Although written for ADAPSO members, almost any computer user should
  90. find it instructive.  The appendices are an excellent source of
  91. further information, addresses and phone numbers, and pointers to
  92. software.  At least one university professor has indicated he will use
  93. the book in a security course, and some law enforcement agencies are
  94. also considering using the book for instructional purposes.
  95.  
  96. The authors are interested in comments and feedback about the book,
  97. especially in areas where information might be added.  You can contact
  98. them by sending mail to "virus-book@cs.purdue.edu"
  99.  
  100. Table of Contents:
  101.   Preface
  102.   Executive Summary
  103.   Introduction
  104.   Programmed Threats
  105.     Definitions
  106.     Damage
  107.     Authors
  108.     Entry
  109.     Summary
  110.   What is a Computer Virus?
  111.     Names
  112.     A History Lesson
  113.     Formal Structure
  114.     How do viruses spread?
  115.     The three stages of a virus's life
  116.     Replication strategies
  117.     Recognizing a viral infection
  118.   Dealing with Viruses
  119.     Prevention
  120.     Detection of a viral infection
  121.     Recovery
  122.     Summary
  123.   Security
  124.     A definition of security
  125.     Security as a goal
  126.     Risk assessment
  127.     Some General Approaches
  128.     Summary
  129.   Legal Issues
  130.     Criminal laws
  131.     Civil suits
  132.     Summary
  133.   Attitudes
  134.   Further Information on Viruses
  135.     Characteristic lengths
  136.     Names of Known Viruses
  137.     Known IBM PC viruses by Characteristics
  138.     Known Apple Macintosh Viruses
  139.     Characteristic resources for Mac viruses
  140.   Information on Anti-Viral Software
  141.     Selected reviews of Anti-viral Software
  142.     Easily obtained software
  143.     Internet Archives
  144.     Other Places to Look
  145.   Further Information on Legal Aspects of Viruses
  146.     Federal Laws
  147.     State Laws
  148.     Other Sources of Information
  149.   Further Reading and Resources
  150.     Organizations and Associations
  151.     Government Agencies
  152.     Journals and Newsletters
  153.     Other Readings
  154.  
  155. A copy can be ordered from
  156.         ADAPSO
  157.         1300 North Seventeenth St.
  158.         Suite 300
  159.         Arlington, VA 22209  USA
  160.         Attn: Mr. John Gracza
  161.  
  162. Single copies are $30.  Copies ordered on university stationary or on
  163. stationary of ADAPSO member companies is only $20, and $16 for the
  164. second and subsequent copies.
  165.  
  166. Requests for review copies or special considerations should be
  167. addressed directly to John Gracza.  Copies have been given away to
  168. ADAPSO member companies, and various state and Federal law enforcement
  169. agencies, so check with others in your organization to see if a copy
  170. isn't already available for review.
  171.  
  172. Overseas orders will be shipped surface mail.  Overseas orders that
  173. are to be shipped air mail should include an additional $10 for
  174. postage.
  175.  
  176. All payment should be in US dollars, no cash or stamps.
  177.  
  178.  
  179. ------------------------------
  180.  
  181. Date:    29 Jan 90 13:24:00 -0400
  182. From:    "Andrew D'Uva" <aduva@guvax.georgetown.edu>
  183. Subject: Security and Internet Worms (Source Code)
  184.  
  185. It seems that the information revolution has brought with it great
  186. problems.  These vast interconnected networks and systems now allow us
  187. to transfer data and programs quickly and at little cost.  The problem
  188. lies in the fact that their level of integration opens them to
  189. infection by worms and trojen horses.  We have even had people ask for
  190. source code for these programs!  Is the solution, as Don Ingli wrote,
  191. to set up some form of reporting mechanism to track these requests?
  192.  
  193. Sadly, I believe it is.  In the United States a certain level of
  194. privacy has been granted as a constitutional right.  That privacy,
  195. however, is not given rights status when it may be demonstrated to
  196. contravene the public good.  In the case of willful and malicious
  197. network destruction/overload/etc, we can only hope that the network
  198. authorities will take pains to trace these people.  The problem, as I
  199. see it, is that no unified network authority exists.  We can hardly
  200. expect to fight the problem without a centralized "clearing house" for
  201. virus information.  This list serves as one such clearing house.
  202.  
  203. However--we still have not (as far as I know) set up a worldwide
  204. security group dedicated to addressing problems like these.  Internet
  205. is so large that this would be hard to do.
  206.  
  207. Yes, I believe that viral source code ought to be distributed and
  208. studied-but under controlled conditions.  The universities offer the
  209. best hope of such a controlled setting.  These problems must be
  210. addressed.  If, as we do in national security issues/clearances, the
  211. focus remains on preventing the outflow of information we risk losing
  212. these battles.
  213.  
  214. -
  215.  -------------------------------------------------------------------------------
  216. - -
  217. Andrew D'Uva
  218. Georgetown University
  219. Washington, D.C.
  220.    Internet: ADUVA@GUVAX.GEORGETOWN.EDU or 76106.3120@CompuServe.COM
  221.    Bitnet  : ADUVA@GUVAX
  222.  CompuServe: 76106,3120
  223.  
  224. ------------------------------
  225.  
  226. Date:    29 Jan 90 21:50:16 +0000
  227. From:    mel@milton.u.washington.edu (Mary Ellen Lee)
  228. Subject: Article on Cliff Stoll
  229.  
  230. I hope someone will correct me if there's a better newsgroup for this:
  231.  
  232. The February issue of Smithsonian magazine has a breezy little article
  233. on Cliff (Cuckoo's Egg) Stoll. Nice coverage of the man, the book, and
  234. the "popularization" of computers in general. It's on page 20.
  235.  
  236. ------------------------------
  237.  
  238. Date:    Mon, 29 Jan 90 09:08:48 -0800
  239. From:    Jim Gillogly <jim%blaise@rand.org>
  240. Subject: Did Morris try to stop the worm?
  241.  
  242. Geof Cooper said:
  243. > One thing that makes me wonder: A newspaper article claims that Morris
  244. > wanted to stop the worm when it started to get out of control, and
  245. > decided that he wasn't able to.  When the Internet group started to
  246. > try and control it, why didn't he offer to help?
  247.  
  248. The following message was sent the morning after the network worm started.
  249. My understanding is that it was sent by a friend of Morris.  Checking the
  250. "Received" times suggests that it it didn't arrive in time to do any good.
  251.  
  252.         Jim Gillogly
  253.  
  254.  --------- Forwarded message -------------
  255. Received: from SRI-NIC.ARPA by rand.org; Sat, 5 Nov 88 03:20:10 PST
  256. Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Fri, 4 Nov 88 23:23:24 PS
  257. T
  258. Received: from cs.brown.edu by RELAY.CS.NET id aa05627; 3 Nov 88 3:47 EST
  259. Received: from iris.brown.edu (iris.ARPA) by cs.brown.edu (1.2/1.00)
  260.         id AA12595; Thu, 3 Nov 88 03:47:19 est
  261. Received: from  (128.103.1.92) with SMTP via tcp/ip
  262.           by iris.brown.edu on Thu, 3 Nov 88 03:34:46 EST
  263. Message-Id: <8811030834.AA10454@iris.brown.edu>
  264. Date: Thu, 3 Nov 88 03:34:13 EST
  265. From: foo%bar.arpa@RELAY.CS.NET
  266. To: tcp-ip@SRI-NIC.ARPA
  267.  
  268. A Possible virus report:
  269.  
  270. There may be a virus loose on the internet.
  271.  
  272. Here is the gist of a message Igot:
  273.  
  274. I'm sorry.
  275.  
  276. Here are some steps to prevent further transmission:
  277.  
  278. 1) don't run fingerd, or fix it to not overrun its stack when reading
  279. arguments.
  280.  
  281. 2) recompile sendmail w/o DEBUG defined
  282.  
  283. 3) don't run rexecd
  284.  
  285. Hope this helps, but more, I hope it is a hoax.
  286. qui
  287.  
  288. ------------------------------
  289.  
  290. Date:    Mon, 29 Jan 90 13:01:38 -0500
  291. From:    "Gregory E. Gilbert" <C0195@UNIVSCVM.BITNET>
  292. Subject: Yet Another WDEF Infection (Mac)
  293.  
  294. WDEF A has made it to The University of South Carolina.  So far I have
  295. only seen one person who has been infected.  I am sure their will be more.
  296.  
  297. If anyone has any ideas how to control it in our Microlabs I would
  298. appreciate hearing from them (any other experiences too.)  Thanks and
  299. happy hunting.
  300.  
  301. Greg
  302.  
  303. Postal address: Gregory E. Gilbert
  304.                 Computer Services Division
  305.                 University of South Carolina
  306.                 Columbia, South Carolina   USA   29208
  307.                 (803) 777-6015
  308. Acknowledge-To: <C0195@UNIVSCVM>
  309.  
  310. ------------------------------
  311.  
  312. Date:    Mon, 29 Jan 90 18:24:57 -0500
  313. From:    V2002A@TEMPLEVM.BITNET
  314. Subject: VAX Virus request and UMNEWS (general)
  315.  
  316. Hi,
  317.  
  318.      Having been a UMNEWS user for 2+ years, I thought that VIRUS-L
  319. should know that ALL users of UMNEWS are required to register by E-MAIL
  320. in order to use the service.  When a new user issues the REGISTER
  321. command the first time, they are sent a copy of the policy for using
  322. UMNEWS.
  323.  
  324.      The policy states explicitly that illegal and unethical use
  325. of UMNEWS will not be tolerated.  It also states that in registering,
  326. the user has read and understood the policy document.
  327.  
  328.      Clearly the request for a VAX virus was in direct violation of
  329. the UMNEWS policy and the requestor stands a good chance of losing
  330. all access to UMNEWS.
  331.  
  332.      The policy document is available from UMNEWS@MAINE on bitnet.
  333. The file name is UMBB POLICY
  334.  
  335.                        Andy Wing
  336.                        Senior Analyst
  337.                        Temple University School of Medicine
  338.  
  339. ------------------------------
  340.  
  341. Date:    Mon, 29 Jan 90 17:06:20 -0400
  342. From:    "Ghassan N. Alkhoja" <ALKHOJA@GWUVM.BITNET>
  343. Subject: Yankee Doodle Virus
  344.  
  345. To all Virus experts,
  346.  
  347. Does anyone out there have any experience with the Yankee Doodle virus.
  348. One of the departments on-campus here at GWU is infected with that virus.
  349. I would appreciate all help that you can provide. Thank you.
  350.  
  351. Ghassan N. Alkhoja
  352. Sr. Programmer/Analyst
  353. Computer Information and Resource Center
  354. The George Washington University
  355.  
  356. ------------------------------
  357.  
  358. Date:    29 Jan 90 19:19:22 +0000
  359. From:    G.Toal@edinburgh.ac.uk
  360. Subject: Prophylactic anti-viral suggestion
  361.  
  362. Dear net friends,
  363.  
  364.    here is a suggestion which may help protect against trojans and viruses --
  365. I haven't seen it mentioned on virus-l (although I've only been reading
  366. it since the start of the Aids scare - the first time I've been personally
  367. affected by viruses) so if I'm repeating an old idea please forgive me.
  368.  
  369.    I use a computer made in the UK called the Acorn Archimedes -- it is a
  370. proprietary RISC cpu, but I can use it with MSDOS programs because it comes
  371. with a pretty good MSDOS emulator: a combination of a CPU emulator, device
  372. emulator, and operating system emulator. (The device emulator attempts to
  373. pass low-level calls like disk i/o through to the Archimedes' disk controller,
  374. the MSDOS emulator runs an emulated ROM but also passes some BDOS commands
  375. through to the host filing system -- for instance, drive F: could come off
  376. a network drive in Archimedes format, not MSDOS.  [The various parts
  377. of the emulation are all implemented in software, I should make clear...]
  378.  
  379.    It occurred to me that a similar program could be run on a *genuine*
  380. MSDOS machine in order to provide a safety wrapper around any programs
  381. which were run on that machine.  (Ie it would still be an emulator, but
  382. it would have a head-start in performance because the emulated CPU &
  383. the real CPU were very similar :-) )
  384.  
  385.    This 'emulator' (I'll call it a 'CPU condom' from now on) would therefore
  386. be able to guarantee that any memory access only came from emulated memory --
  387. no program would be able to muck around with real memory.  It would only allow
  388. access to the devices which the user chose to allow (eg, clock - yes,
  389. disk controller - no); and it would trap all higher-level BDOS/BIOS calls
  390. in order to ask the user (say by switching to an alternate screen display
  391. and back again) whether he/she wanted to allow any particular file to
  392. be written to.
  393.  
  394.    The CPU condom would probably not be able to allow a full 640K to
  395. the running program - I don't know - that's for MSDOS experts to work out.
  396. With a program like this, you would be able to run any unknown code
  397. with complete confidence.  It could be parameterized so that particular
  398. programs being run always were allowed to write only to specific directories,
  399. to save users having to say 'yes' or 'no' every time a file was being
  400. written.
  401.  
  402.    Unfortunately, I don't have the expertise to write this myself, (I
  403. know very little of MSDOS or 808X's and really don't want to waste brain-cells
  404. learning it ;-) )  but the readership of this list is sufficiently wide
  405. that writing such a system may appeal to someone.
  406.  
  407. Over & out,
  408.   regards,
  409.     Graham Toal   <gtoal@ed.ac.uk>
  410.  
  411. PS If written portably, an MSDOS emulator which did solely file I/O
  412. and screen/keyboard I/O would be usable on other systems -- especially
  413. useful for things like unpacking self-extracting .exe files on unix
  414. mainframes -- almost impossible otherwise.  (I have countless numbers
  415. of archive unpackers on our local Unix machine to save telephone
  416. bandwidth when I fetch something from a server and discover I only
  417. want 15% of the archive it came in!)
  418.  
  419. ------------------------------
  420.  
  421. Date:    30 Jan 90 01:03:10 +0000
  422. From:    munnari!dbrmelb.oz.au!steveo@dbrmelb.dbrhi.OZ (Stephen Oakes)
  423. Subject: Possible new virus?? NUCLEUR WAR.
  424.  
  425. A Friend Of A Friend had this happen on his XT upon booting from the
  426. Hard Disc.  A message appeared saying something like:
  427.  
  428. "    Welcome Home !!!!
  429.      I have had a good rest, have you?
  430.  
  431.      Now, lets get down to business.
  432.  
  433.      Do you want ...  THERMO NUCLEUR WAR!
  434.  
  435.      Press any Key to continue.
  436. "
  437.  
  438. (I'm not sure if "NUCLEAR" was originally mispelt, or copied down
  439. incorrectly)
  440.  
  441. The FOAF immediately switched his computer off, and is now preparing
  442. to reformat his Hard disc.  If this is a virus, it probably came form
  443. games software which the FOAF copied from A Friend.  I know nothing
  444. about where the FOAFOAF gets his software.
  445.  
  446.     Anyone know anything about this one?
  447.  
  448. Stephen Oakes : steveo@dbrmelb.dbrhi.oz
  449.  
  450. ------------------------------
  451.  
  452. Date:    Mon, 29 Jan 90 23:34:00 -0500
  453. From:    Leichter-Jerry@CS.YALE.EDU
  454. Subject: Universal virus detectors
  455.  
  456. All this debate about whether virus detection is equivalent to the
  457. halting problem, whether real CPU's are best modeled and FSA's or
  458. Turing machines, and so on, is interesting but in a deep sense
  459. completely irrelevant.
  460.  
  461. With simple hardware support, one can design a system in which all
  462. viruses are trivial detectable.
  463.  
  464.         Technique:  The hardware will maintain, in both memory and
  465.         on disk, an "is executable code flag".  For practicality,
  466.         assume this is done on a block-by-block basis say in units
  467.         of a K.
  468.  
  469.         The hardware enforces the following rules:
  470.  
  471.         1.  Any attempt to execute code from a memory block which
  472.         is not marked executable fails.
  473.  
  474.         2.  The only way to write into a block of memory that is
  475.         marked executable is from a disk block marked executable.
  476.  
  477.         3.  Any attempt to write to a disk block marked executable
  478.         fails.  (To write to such a block, the executable flag must
  479.         first be cleared.)
  480.  
  481.         4.  Any disk block can be marked executable at any time.
  482.  
  483.         Memory blocks are marked executable only by reading execu-
  484.         table disk blocks into them.
  485.  
  486.         5.  Associated with every disk block is a time stamp.  When
  487.         a block is marked executable, the hardware updates its time-
  488.         stamp.
  489.  
  490.         6.  The system comes with physical ROM blocks, marked exe-
  491.         cutable, which contain at least the code needed to display
  492.         the timestamps on all executable blocks.
  493.  
  494. One could obviously come up with a simpler system - e.g., just keep a
  495. timestamp on EVERY block - but this one is close to practical.  The
  496. sticky spot is 4, which makes it impossible to build executable code
  497. without going through the disk.  Building disk caches for such a
  498. system would also be a complex undertaking.  On the other hand, the
  499. rules are so simple that one could attain a very high degree of
  500. confidence that the hardware was enforcing them correctly.
  501.  
  502. Why does this work, despite all the proofs?  (Note that it works just
  503. fine even if the disk is assumed to be infinite, in which case the
  504. machine is a Turing machine.  If you are worried about the theoretical
  505. problem of repeated time-stamps - just use variable-length
  506. time-stamps, which are no problem on an infinite disk.)  It works
  507. because none of the standard models have anything that corresponds to
  508. the timestamp: Memory that can be written by the system, but not by
  509. externally-controllable code within the system.
  510.  
  511.                                                         -- Jerry
  512.  
  513. ------------------------------
  514.  
  515. Date:    30 Jan 90 04:45:11 +0000
  516. From:    annala%neuro.usc.edu@usc.edu (A J Annala)
  517. Subject: Re: Virus request
  518.  
  519. >> >        Dose anyone have a idea about VAX Virus? Or interesting on
  520. >> >        it? I think the most difficult point is how to spread it
  521. >> >        out. So if someone has any bright idea, contact with me.
  522. >
  523. >What as a whole can the computer industry do to help prevent individuals
  524. >like this from the potential releasing of these viruses(viri?) into the
  525. >vast networks??  Should it be illegal to own or transmit virus source
  526. >(for non-security personnel)??  Also, should there be an international
  527. >watchdog agency set up to investigate such requests??  Should the
  528. >CIA/FBI/FCC be involved in cooperation with IBM/DEC/AT&T/etc.. to form a
  529. >task force along with our list's virus expert?  Has anyone contacted this
  530. >person's administration along with MAINE's and BITNIC/BITNET administration?
  531. >Right now, its up to us to report these requests and its the responsibility
  532. >of MAINE to act on requests submitted via UMNEWS.
  533. >
  534. >Can we make it illegal to have virus sources without stomping on our
  535. >constitutional rights??  What about other countries??
  536. >
  537. >Obviously this particular Taiwanese knows little about VAX networking and
  538. >uses of viruses(worms) in those networking facilities.
  539.  
  540. There are people who write computer programs (including viruses) and there
  541. are people who only use computer programs (including viruses).  It would
  542. appear that the originator of the request for a VAX Virus is a member of
  543. the latter group.  While it is rather amusing that the requestor could be
  544. so terribly naive as to post his note to a public newsgroup, I seriously
  545. doubt he would be sufficiently competent to introduce a virus into DECNET,
  546. SNA, TCP based networks.  Calling out the computer gestapo in this case may
  547. seem a little heavy handed.  Perhaps someone would consider sending him a
  548. friendly note explaining the damaging potential of actually introducing one
  549. of the responses to his request into a live computer network.  One might be
  550. tempted to highlight the potential administrative/regulatory response to the
  551. actual use of the information gleaned from his request.
  552.  
  553. NO.  One cannot forbid the possession of sources, linkable objects, or even
  554. executables for a virus without doing fundamental harm to the Bill of Rights.
  555. Viruses may be an unpopular idea ... but the protection of the right of the
  556. individual to free expression of his ideas ... and the right to share those
  557. ideas with other people is fundamental to the concept of a free society.  If
  558. one encroaches on the fundamental right of free speech (including writing)
  559. then one does fundamental damage to our constitutional guarantees.  Moreover,
  560. even if you would allow such a prohibition in spite of it's constitutional
  561. implications, the regulation would most likely be unenforceably broad.  It
  562. would be all but impossible to distinguish the program category "virus" from
  563. other less virulent programs.  Let's keep to prosecuting harmful use of such
  564. material rather than mere possession of unpopular ideas.
  565.  
  566. AJ
  567.  
  568. ------------------------------
  569.  
  570. Date:    30 Jan 90 06:34:49 +0000
  571. From:    khijol!erc@cs.utexas.edu (Ed Carp, aka Mr. Ed the talking horse...)
  572. Subject: Re: Virus request
  573.  
  574. woodb!scsmo1!don@cs.UMD.EDU writes:
  575.  
  576. >He will probably get a few replies as well as some sources. What as a
  577. >whole can the computer industry do to help prevent individuals like
  578. >this from the potential releasing of these viruses(viri?) into the
  579. >vast networks??
  580.  
  581.  Not a whole lot, except to take reasonable security precautions.
  582.  
  583. >Should it be illegal to own or transmit virus source (for non-security
  584. >personnel)??
  585.  
  586.  No.  How would you define the term "security personnel"?  I can write
  587. a virus with a little effort.  Does this make me a criminal?  Of
  588. course not!  Similarly, I have a complete set of lockpicking tools.
  589. Does this make me a criminal?  Again, the answer is no.  It's not the
  590. tool, it's the use of the tool.  Remember, you can design a workable
  591. atomic bomb from documents that you can find at most any large public
  592. library.  Why should it be different for anything else?  Let's not get
  593. swept up in this anti-virus hysteria -- let's see some reason.
  594.  
  595. >Also, should there be an international watchdog agency set up to
  596. >investigate such requests??  Should the CIA/FBI/FCC be involved in
  597. >cooperation with IBM/DEC/AT&T/etc.. to form a task force along with
  598. >our list's virus expert?
  599.  
  600. I think this is going a bit overboard.  Sounds like paranoid hysteria.
  601.  
  602. >Has anyone contacted this person's administration along with MAINE's
  603. >and BITNIC/BITNET administration?
  604.  
  605. >Right now, its up to us to report these requests and its the
  606. >responsibility of MAINE to act on requests submitted via UMNEWS.
  607.  
  608.  Really?  Who appointed "us" net.police?  Or net.censor?
  609.  
  610. >Can we make it illegal to have virus sources without stomping on our
  611. >constitutional rights??  What about other countries??
  612.  
  613.  I doubt it.
  614.  
  615. Right after the Internet virus was released, I saw several postings
  616. requesting source for the virus.  Sure, there were probably net.idiots
  617. who wanted to take the source, hack it up, and re-release it, but
  618. there were obviously sincere, rational investigators who wanted to
  619. investigate the virus, tear it apart, figure out just how it worked,
  620. and then build a better virus-catcher.  There are people who are out
  621. there who make money by doing this sort of thing.  Are you suggesting
  622. that the people who have already become established (known) in the
  623. field have some sort of exclusive on source?  Who appointed Gene
  624. Spafford the net.virus.god?  This is NOT a flame against Gene, but I
  625. have a dim view of folks who want to set up Gene and others like him
  626. on a pedestal.  I respect Gene's abilities in his field, but there are
  627. lots of programmers who can do the same thing.
  628.  
  629. If someone wants to write a virus, he can sure do it without having
  630. access to source.  Who's going to judge?  If I ask for source (hey,
  631. Gene, can you mail me the latest source to the Internet virus?), does
  632. that make me automatically suspect?  Am I a "bad guy"?  I could forge
  633. my mail address, looking like I come from IBM's Virus Research Group
  634. (thinking about it, I don't really *need* to forge THAT), send Gene a
  635. request, then, when I get the source, use it for my own nefarious
  636. purposes.  Alternately, I could be doing genuine virus research for
  637. defending AIX against viruses.  There IS such work going on, you know.
  638.  
  639. I could even be legit.  I sub-contract for IBM.  This gives me access
  640. to IBM's facilities, phones, etc.  I could pose as a virus research
  641. (or even BE a virus researcher), get the source, and do whatever.
  642.  
  643. Just because one is a "security expert" doesn't make them a "good guy"; just
  644. because one isn't doesn't make them a "bad guy".
  645. - --
  646. Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
  647. Austin, Texas           (512) 832-5884          "Good tea.  Nice house." - Worf
  648. "Love in any language, fluently spoken here"             -- sung by Sandi Patti
  649.  
  650. ------------------------------
  651.  
  652. Date:    30 Jan 90 05:22:52 +0000
  653. From:    wcpl_ltd@uhura.cc.rochester.edu (Wing Leung)
  654. Subject: Re: WDEF at University of Rochester (Mac)
  655.  
  656.         WDEF B is found in University of Rochester.  Tonight I've found
  657. one of my disk crash due to a problem in the Desktop file.  After recovering
  658. it at the Computer Center, we use Disinfectant 1.5 to scan the Desktop file
  659. and WDEF B is found.  My friend use it to scan his disks too.  The earliest
  660. infection found so far is on 22nd Jan.
  661.  
  662. Peter
  663.  
  664.   _    _  ____  ____   _        * Internet:     wcpl_ltd@uhura.cc.rochester.edu
  665.  (/   /  //  / //   ) (/        * BITNET  :     WCPL_LTD@UORDBV
  666.  / / /  //    //___/ _/         * DecNet  :     UORHEP::PETER
  667. /_/_/  //__/ //     _/\___/     * UUCP    :     ...rochester!uhura!wcpl_ltd
  668.  
  669. ------------------------------
  670.  
  671. Date:    Tue, 30 Jan 90 11:54:32 +0000
  672. From:    "Dr. A. Wood" <XPUM01@prime-a.central-services.umist.ac.uk>
  673. Subject: re: 'Virus request' from Taiwan
  674.  
  675. ......Re this message:-
  676. From:  IN%"UMNEWS@MAINE.BITNET"  "Vax discussion" 21-JAN-1990 23:11:59.77
  677. Subj:  <Vax 85> Virus on VAX
  678. From: 7811100@TWNCTU01.BITNET
  679.  
  680. Hi! Does anyone have a idea about VAX Virus? Or interesting on it? I
  681. think the most difficult point is how to spread it out. So if someone
  682. has any bright idea, contact with me. James Huang
  683.  
  684. ......and this reply to it:-
  685. Date:    Thu, 25 Jan 90 12:08:35 -0500
  686. From:    woodb!scsmo1!don@cs.UMD.EDU
  687. Subject: RE: Virus request
  688.  
  689. Here is a message from UMNews's Vax discussion list. I thought the
  690. list should know about this. The node is Taiwanese.  This is insane.
  691. Obviously this particular Taiwanese knows little about VAX networking
  692. and uses of viruses (worms) in those networking facilities. He will
  693. probably get a few replies as well as some sources. What as a whole
  694. can the computer industry do to help prevent individuals like this
  695. from the potential releasing of these viruses into the vast networks??
  696. Should it be illegal to own or transmit virus source (for non-security
  697. personnel)?? Also, should there be an international watchdog agency
  698. set up to investigate such requests?? Should the CIA/FBI/FCC be
  699. involved in cooperation with IBM/DEC/AT&T/etc.. to form a task force
  700. along with our list's virus expert? Has anyone contacted this person's
  701. administration along with MAINE's and BITNIC/BITNET administration?
  702. <etc etc>
  703. .............................................................................
  704.  
  705. If James Huang is Taiwanese, then his first and most familiar language
  706. is likely not English but Chinese, and likely he committed no computer
  707. ethical error but merely a language blunder, namely the common capital
  708. offence of 'unclear use of a pronoun'!  <WOODB!SCSMO1!DON@CS.UMD.EDU>,
  709. in the course of emptying his  flamethrower down the  computer link at
  710. the  unfortunate Huang, seems to   imply that Huang   meant "I want to
  711. spread VAX virus".  But Huang could also have intended to say  "I want
  712. to spread news about how to notice and combat VAX virus"
  713.  
  714. - - which is what Virus-L is for!!
  715. {A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Tue, 30 Jan 90 11:25:08 GMT
  716.  
  717. ------------------------------
  718.  
  719. Date:    Tue, 30 Jan 90 08:18:29 -0500
  720. From:    Jim Ennis <JIM@UCF1VM.BITNET>
  721. Subject: WDEF Infection (Mac)
  722.  
  723. Hello,
  724.  
  725.   We had a WDEF infection of our Mac lab at the University of Central
  726. Florida.  The person fixing the viruses traced the source back to a
  727. local copy center which has some Mac for use on a hourly basis and
  728. students brought their infected disks from the store to our Mac lab.
  729. The person who kills viruses for us has cleaned up the Macs in our
  730. lab.
  731.  
  732.  -----------------------------------------------------------------------------
  733.  Jim Ennis
  734.  UCF - Computer Services
  735.  JIM@UCF1VM.BITNET
  736.  
  737. ------------------------------
  738.  
  739. End of VIRUS-L Digest
  740. *********************
  741. Downloaded From P-80 International Information Systems 304-744-2253
  742.