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

  1. VIRUS-L Digest              Friday, 3 Feb 1989          Volume 2 : Issue 35
  2.  
  3. Today's Topics:
  4. Hardware lock (PC)
  5. Re: Anti-virus viruses
  6. The Media and Viruses
  7. Review of antenna program
  8. Ethical issues.
  9. Gatekeeper Report (Mac)
  10. nVIR Assassin... (Mac)
  11. VIRUS WARNING: Lehigh Virus version II (PC)
  12.  
  13. ---------------------------------------------------------------------------
  14.  
  15. Date:         Wed, 01 Feb 89 16:06:25 CST
  16. From:         James Ford <JFORD1@UA1VM.BITNET>
  17. Subject:      Hardware lock (PC)
  18.  
  19. On a computer with a hard drive, is there any way to (hardware) fix
  20. drive "A" so that the computer will always boot from "C" and yet still
  21. have the use of "A"?  (boot from C always, read/write from A and C)
  22.  
  23. This may/may not be the correct list to post this to, but I would be
  24. interested in your comments.  (I guess you could stop SOME destructive
  25. programs from spreading this way....)
  26.  
  27.                            James Ford
  28.                            JFORD1@UA1VM.BITNET
  29.  
  30. ------------------------------
  31.  
  32. Date: Wed, 1 Feb 89 17:50 EST
  33. From: "Mark H. Anbinder" <THCY@VAX5.CCS.CORNELL.EDU>
  34. Subject: Re: Anti-virus viruses
  35.  
  36. One of the ways viruses cause problems is the incidence of accidental
  37. memory-related or incompatibility-caused crashes or similar
  38. situations, simply when they propogate.  Viruses don't need to
  39. intentionally DO something to cause a disk crash or a system crash.
  40.  
  41. An anti-virus virus would probably cause the same types of problems as
  42. it replicated itself trying to seek out nasties.  It would be nearly
  43. impossible to write such a program that guarded against MOST possible
  44. incompatibilities or memory-management problems, much less against ALL
  45. possible such problems.
  46.  
  47. Releasing an anti-virus virus upon the world would be similar to the
  48. MacMag virus, which was (theoretically) intended to bring the possible
  49. threat of viruses to the attention of the computing world.  It would
  50. also be similar to the motive some people claim for Robert Morris (one
  51. fellow Cornellian of whom I am NOT proud), of warning people of what a
  52. virus might do if someone MEAN had written it.  It would be
  53. irresponsible in the extreme, and would, most likely, cause more
  54. problems than it would solve, even if no one tried to modify it to be
  55. intentionally harmful.
  56.  
  57. Mark H. Anbinder
  58. THCY@CRNLVAX5
  59. THCY@VAX5.cit.cornell.edu
  60. Department of Media Services
  61. Cornell University
  62.  
  63. ------------------------------
  64.  
  65. Date:         Thu, 02 Feb 89 02:46:38 EST
  66. From:         Greg Brail <ST601396@BROWNVM.BITNET>
  67. Subject:      The Media and Viruses
  68.  
  69. There's been a lot of complaining recently about how "The Media" has
  70. been misleading the public about viruses. As a semi-legitimate member
  71. of The Media and as someone who considers himself knowledgeable about
  72. computers, I think some clarification is in order.
  73.  
  74. Basically, reporters try to write stories that people are going to
  75. want to read. If a story for a non-technical publication gets bogged
  76. down in techno-speak, readers can just as easily read something else.
  77. Writing an accurate article about a technical subject like computer
  78. viruses that the average reader can understand can be difficult, to
  79. say the least.
  80.  
  81. I know this because I just wrote an article about viruses for the
  82. Brown Daily Herald, the student newspaper here. Perhaps I should
  83. assume that Brown students would have an easier time with such an
  84. article than an "average person." I didn't.
  85.  
  86. In my article, I referred to the Internet worm as a "virus." The day
  87. the article ran, I read in this mailing list that the proper term for
  88. the program was "worm," not "virus." Had I known that, I would have
  89. corrected the terminology in the article.
  90.  
  91. But the truth is that it probably wouldn't have made much of a
  92. difference.  To the "average person," a virus is a nasty program that
  93. spreads itself from one computer to another and can do bad things.
  94. That's probably all anyone needs to know.
  95.  
  96. What computing professionals must understand is that they must be
  97. careful when explaining viruses, or any computer-related issue for
  98. that matter, to a reporter. Even if the reporter doesn't ask, "What's
  99. a virus," you should probably explain it anyway. If a reporter asks
  100. you about the "Internet virus," you should point out that that program
  101. was a worm, not a virus. Reporters don't (usually) make things up. If
  102. you don't give them the correct information, they will assume
  103. something that looks like a virus is, in fact, a virus, whether
  104. they're right or not.
  105.  
  106. I, too, objected to Newsweek's insinuation that the games spreading
  107. through Germany are viruses, although a one-sentence clarification
  108. near the top of the article would have been fine. I also wondered why
  109. the New York Times and other publications didn't realize that when
  110. people hear that "defense department computers were the victim of a
  111. virus," the think that the computers that launch nuclear missiles were
  112. infected.  And the improper use of the term "hacker" really ticks me
  113. off.
  114.  
  115. However, the truth is that many journalists are not stupid, ignorant,
  116. or "J-school morons." The best rule for journalists writing about
  117. technical issues is to pretend you don't know anything so your sources
  118. will explain it for you. When talking to journalists, computing
  119. professionals should use the same rule. Don't assume the reporter
  120. knows everything about computers, unless you know that particular
  121. reporter's work. Take the time to clarify what you're talking about.
  122. Many reporters will not stop you if you go too fast, although they
  123. should.
  124.  
  125. Of course, none of this can happen if the computing community cannot
  126. decide upon and spread the word about the proper definition of "virus"
  127. and other terms. Unfortunately, today's computer users have to know
  128. how to protect themselves from viruses. If the computing community
  129. takes the responsibility of spreading accurate information to
  130. reporters, good reporters will take the responsibility of spreading it
  131. to the public.
  132.  
  133. Greg Brail
  134. ST601396@brownvm.brown.edu
  135. ST601396@brownvm.BITNET
  136. P.O. Box 1020
  137. Brown University
  138. Providence, RI 02912
  139.  
  140. ------------------------------
  141.  
  142. Date:       Thu, 2 Feb 89 10:32:18 GMT
  143. From:       David.J.Ferbrache <davidf@CS.HW.AC.UK>
  144. Subject:    Review of antenna program
  145.  
  146. [Ed. The following message was sent to the United Kingdom distribution
  147. of VIRUS-L.  Apologies to our UK readers who are reading this for the
  148. second time.]
  149.  
  150. For anyone interested, there was an Antenna presentation on Computer
  151. viruses on BBC2 last night. Here is a brief review of the material
  152. covered. I guess anyone interested in obtaining a transcript of the
  153. program should contact the BBC.
  154.  
  155. This program provided an overview of the topic of computer viruses,
  156. the risk and the possible cures. The concept of a computer virus was
  157. explained using the traditional biological analogy, by both Dr A
  158. Solomon (IBMPCUG) and Ian MacKay a biologist from Glasgow University.
  159. Parallels were drawn between the AIDS virus' ability to disguise
  160. itself by changing surface characteristics and that of the computer
  161. virus by changing host program.  (This ability is extended in newer
  162. viruses such as the 1701-Blackjack virus in which the majority of the
  163. virus object code is encrypted when on secondary storage).
  164.  
  165. Examples were presented of infection of IBM PC compatibles (by the
  166. Italian virus), the Apple Mac (by nVIR a) and the Amiga (by the SCA
  167. virus). The program demonstrated the use of Turin university
  168. anti-viral software and the use of Interferon and Vaccine. The
  169. conclusion seemed to be that it is a continuous battle between the
  170. vaccine developers and the hacker virus writers. In such a battle
  171. vaccine writers are at an obvious disadvantage as they strive to
  172. obtain information on, and develop countermeasures for new virus
  173. strains.
  174.  
  175. Interviews were given with a number of computer "hackers", and
  176. included footage of the Vaxbusters interest group of the Chaos
  177. Computer Club; together with demonstrations of actual breakins to the
  178. computer systems of Singapore Airlines and NASA. The integrity of a
  179. number of commercial bank computer systems was also questioned,
  180. including that of Chase Manhatten.
  181.  
  182. The program gave a frightening, and emotive portrayal of computer
  183. viruses, trojan horses (including Larry the Lounge Lizard), and the
  184. insecurity of mainframe systems. The program enumerated three possible
  185. courses of action against computer viruses, namely: vaccine
  186. development, change computer and legislation. The conclusion was that
  187. vaccines will become impractical as the threat from, and diversity of
  188. viruses grows. (Since the source of two viruses has now been
  189. published, the threat seems certain to grow).
  190.  
  191. The inference that legislation is necessary with greater restrictions
  192. on computer access seemed obvious.
  193.  
  194. Dave Ferbrache                            Personal mail to:
  195. Dept of computer science                  Internet <davidf@cs.hw.ac.uk>
  196. Heriot-Watt University                    Janet    <davidf@uk.ac.hw.cs>
  197. 79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
  198. Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553
  199.  
  200. ------------------------------
  201.  
  202. Date:         Thu, 02 Feb 89 09:23:01 EST
  203. From:         "John P. McNeely" <JMCNEELY@UTCVM.BITNET>
  204. Subject:      Ethical issues.
  205.  
  206.      Currently there are a wide variety of viruses infecting various
  207. machines across the world. We know the names of the virues and the
  208. damage that they do. But, with the exception of a few viruses and
  209. WORMS, we don't know who the culprits are behind this. What are the
  210. ethics behind writing viruses and WORMS? The controversey still
  211. surrounds Robert Morris jr. and his motives; the Pakistani brothers
  212. wanted to teach people lessons about software piracy. What about the
  213. others? We probably will never know who started what, but we can
  214. ponder the questions as to why a person would want to write a computer
  215. virus or WORM.
  216.  
  217. Any thoughts on this?
  218.  
  219. Respond to me either directly or to the list. Thank you.
  220.  
  221. John P. McNeely
  222.  
  223. BITNET Address: JMCNEELY@UTCVM.BITNET
  224.  
  225. ------------------------------
  226.  
  227. Date:     Thu, 02 Feb 89 20:22:22 PST
  228. From:     SPOCK@CALSTATE.BITNET  (Commander Spock)
  229. Subject:  Gatekeeper Report (Mac)
  230.  
  231. Although I am *NOT* the author of the program, I would like to post a
  232. notice to those who are currently or will be using Gatekeeper, this
  233. notice may come in handy.  Aside from the notices that the author has
  234. published (from what I can count, currently: 2 posted), I find the
  235. program quite useful in performing searches for various "virus
  236. attacks".  At any rate, I will let you folks (not to mention the
  237. author) know of any problems that I've run acrossed when using
  238. Gatekeeper.  I hope that other users/developers/authors will
  239. reciprocate with their findings.
  240.  
  241. Current system setup is as follows:
  242.  
  243.    - Macintosh Plus == 1MB RAM configuration
  244.    - RAM cache OFF
  245.    - 1 Jasmine 100MB hard drive
  246.    - 1 external 800K floppy drive
  247.    - various CDEV's including Gatekeeper
  248.    - Suitecase II Release 1.0.2
  249.  
  250. Finding:
  251.  
  252.    1. Have recently upgraded System file to 6.0.3
  253.    2. Have recently upgraded Finder file to 6.1
  254.    3. Have recently upgraded Control Panel to 3.3.1
  255.  
  256. Observed Problems:
  257.  
  258.    1. Gatekeeper *DOES NOT* register inside the Control Panel
  259.    2. Miscellaneous error dialogs keep popping up:
  260.  
  261.       - ID = 02
  262.       - ID = 03
  263.       - ID = 22
  264.       - ID = 15
  265.  
  266. I realize that the 22 and 15 errors may (or may not) have been
  267. directly or indirectly related to the execution of Gatekeeper within
  268. the Control Panel, provided of course that the close option within the
  269. box (the square) has *NOT* been initiated; otherwise, the resulting
  270. error is an ID = 02.
  271.  
  272. Could I possibly be doing something wrong?  Second, is there a chance
  273. that I may be able to obtain a copy of the program (source not
  274. necessary) to debug myself (to those who have Gatekeeper 1.0.1)?
  275. Three, any further findings that I find unusual simply by having
  276. Gatekeeper within my System Folder, I will let you folks know.  I feel
  277. that sharing information with those who may be directly or indriectly
  278. affected by the proper executing and dependance of this file is a
  279. must, not a necessity.  I hope that others can feel the same about any
  280. quirks that they may find with this file and others for the Macintosh
  281. and/or IBM.
  282.  
  283. Should I stand to be corrected (and I have been known to make
  284. mistakes...), please let me know what I might be doing wrong.
  285.  
  286. With best regards,
  287.  
  288. Robert S. Radvanovsky          spock%calstate.bitnet@cunyvm.cuny.edu
  289. California Polytechnic Univ.   spock@calstate.bitnet
  290. Pomona, California
  291.  
  292. P.S.  I admit, I'M HUMAN!  Kind of a bad position for me, wouldn't you
  293. think?
  294.  
  295. ------------------------------
  296.  
  297. Date:     Thu, 02 Feb 89 20:43:22 PST
  298. From:     SPOCK@CALSTATE.BITNET  (Commander Spock)
  299. Subject:  nVIR Assassin... (Mac)
  300.  
  301. Need some help here.  I have "nVIR Assassin", version 1.0.  I've used
  302. it on various machines and removed copies of "nVIR", supposedly.  What
  303. happened was this: of the 6 applications that were checked, only 2
  304. worked correctly.  The programs checked were:
  305.  
  306.    - Microsoft Excel 1.05
  307.    - Microsoft Works 2.0
  308.    - Reflex Plus
  309.    - Filemaker 4
  310.    - Font/DA Mover 3.6
  311.    - Hypercard 1.2.1
  312.  
  313. Of the programs that worked, only Font/DA Mover and and Filemaker 4
  314. worked.  All other programs simply exited to the Finder.  Have I done
  315. something wrong?  I've performed all the necessary steps needed as
  316. outlined by the author.  What happened?
  317.  
  318. Robert S. Radvanovsky          spock%calstate.bitnet@cunyvm.cuny.edu
  319. California Polytechnic Univ.   spock@calstate.bitnet
  320. Pomona, California
  321.  
  322. ------------------------------
  323.  
  324. Date:         Fri, 3 Feb 89 07:58:56 EST
  325. Sender:       Virus Alert List <VALERT-L@IBM1.CC.Lehigh.Edu>
  326. From:         Ken van Wyk <luken@SPOT.CC.LEHIGH.EDU>
  327. Subject:      VIRUS WARNING: Lehigh Virus version II (PC)
  328.  
  329. A new version of the Lehigh Virus has appeared on our campus; it is
  330. almost identical to the first one, but has a couple of notable
  331. differences.
  332.  
  333. Yesterday, one of our microcomputer labs reported several students'
  334. disks being destroyed.  We were able to determine that a virus which
  335. appeared identical (at first) to the Lehigh Virus had indeed infected
  336. some of the disks in the public lab.  Disassembly of the virus was
  337. quick and painless because it beared so much resemblance to the
  338. original Lehigh Virus.
  339.  
  340. The important differences are:
  341.  
  342. 1) "Version II" waits until its generation counter hits 10 before
  343. doing any destruction.
  344.  
  345. 2) II does not store the generation counter on disk, as version I did
  346. in the case of hard disk machines.  That is, a system reboot starts
  347. the generation counter back at 0.
  348.  
  349. Because of these seemingly minor differences, the virus has a greater
  350. potential for spreading.
  351.  
  352. Both versions can be referred to as FEVs (Feature Exploiting Viruses)
  353. since they use MS-DOS Interrupt 21H functions for propagating, and
  354. a slightly lower level routine, Interrupt 26H (Absolute Disk Write) to
  355. destroy the boot track of disks (floppy and fixed) once the generation
  356. counter hits 10 (for version II, 4 for version I).
  357.  
  358. Any/all followups will be posted on VIRUS-L.
  359.  
  360. Ken van Wyk
  361. Lehigh University Computing Center
  362.  
  363. [Ed. Editor's apologies for taking so long to get this VIRUS-L digest
  364. together.  The above message should explain why we've been a bit busy
  365. around here...  :-)  With the help of a *very* talented and willing
  366. crew, things seem to be pretty much under control.  Thanks to all!]
  367.  
  368. ------------------------------
  369.  
  370. End of VIRUS-L Digest
  371. *********************
  372. Downloaded From P-80 International Information Systems 304-744-2253
  373.