home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / virus / virusl2 / virusl2.33 < prev    next >
Text File  |  1995-01-03  |  11KB  |  238 lines
  1. VIRUS-L Digest             Wednesday, 1 Feb 1989        Volume 2 : Issue 33
  2.  
  3. Today's Topics:
  4. 'Virus' term usage
  5. Re: CP/M Viruses
  6. Re: Virus Terminology
  7. Re: Origin of the term `virus'
  8. Virus epidemics.  Is the hype too much?
  9. Categorizing viruses
  10.  
  11. ---------------------------------------------------------------------------
  12.  
  13. Date:     Tue, 31 Jan 89 10:02:08 EST
  14. From: Jefferson Ogata (me!) <OGATA@UMDD.BITNET>
  15. Subject:  'Virus' term usage
  16.  
  17. One simple reason the term 'virus' wouldn't be used of code before 5
  18. or so years ago is that until about 9 or 10 years ago, the general
  19. public wasn't all that familiar with the details of how a biological
  20. virus works.  And those who did know probably wouldn't bother using
  21. the term, since few would understand why it would be appropriate.
  22.  
  23. You'll also find that in the Middle Ages, not many people used the
  24. term even for biological viruses.  :-)
  25.  
  26. - - Jeff Ogata
  27.  
  28. ------------------------------
  29.  
  30. Date:         Tue, 31 Jan 89 10:22:13 EST
  31. From: Art Larky  <AIL0@LEHIGH>
  32.                 215 Packard Building 19
  33. Subject: Re: CP/M Viruses
  34.  
  35.   I don't know of any CP/M viruses and I suspect there were few or
  36. none.  The current virus outbreaks are based upon a couple of things
  37. which weren't applicable to CP/M:
  38.   (1) There wasn't as much trading of files and disks because there
  39. wasn't as many personal computers and Bulletin Boards around.
  40.   (2) CP/M systems were not accessible at the hardware level to the
  41. same extent as PC's because everyone's hardware was different.  My
  42. BIOS is similar to those of other persons, but the underlying ROM
  43. routines are ones that I wrote myself; the disk addresses were chosen
  44. by me; my screen display is similar to some, but not all CP/M systems.
  45. In fact, my screen display is different from the one I started with
  46. and I had to change my programs and my ROM because of it.
  47.   (3) There weren't as many assembly language programmers out there
  48. because there weren't as many computers by a factor of 100,000 or
  49. 1,000,000 to 1.  The more people who have computers to play with and
  50. know how to program, the greater the likelihood of there being a
  51. combination of weirdo and programming in one sicko.
  52.  
  53.   All of which supports what I said before, you can protect yourself
  54. from some viruses by making your system different; e.g., your own
  55. names for files like autoexec.bat and command.com.
  56.  
  57. Art Larky
  58. CSEE Dept
  59. Lehigh University   I know I'm not speaking for Lehigh University,
  60.                     there's no reason for you to think so either.
  61.  
  62. ------------------------------
  63.  
  64. Date:     Tue, 31 Jan 89 10:32:16 EST
  65. From:     Jefferson Ogata (me!) <OGATA@UMDD.BITNET>
  66. Subject:  Re: Virus Terminology
  67.  
  68. J. Yeidel writes that 'virulent' is an inappropriate word for a virus
  69. that spreads rapidly within a system, and that 'extremely contagious'
  70. would be better.  I must disagree with the second point, as 'extreme-
  71. ly contagious' implies that the virus spreads from system to system
  72. quickly.  In fact, a virus's contagion depends on its contact with the
  73. outside world, which is usually dependent on human factors -- does a
  74. person swap disks often? etc.
  75.  
  76. Regarding 'benign', I think most people use it in a relative sense; no
  77. one really means the virus does no damage, although viruses could
  78. exist that do no damage (even as far as destroying themselves to avoid
  79. wasting humans' time).  However, 'benign' could be applied to the
  80. 'virulent' problem, in the sense it is used in describing tumors:
  81. namely, a 'benign' virus would be one that doesn't spread throughout a
  82. machine, and a 'malignant' virus would be one that does.  At pres-
  83. ent, 'malignant' cannot be used easily because of its ambiguity in
  84. this regard.  And a 'benign virus' may truly be a contradiction in
  85. terms, I suppose.  However, a virus could be 'benign' under some
  86. circumstances and 'malignant' under others.
  87.  
  88. 'Misimpressions'?  Surely you mean 'false impressions'. :-)
  89.  
  90. - - Jeff
  91.  
  92. [Ed. I think that all of this points out yet again that there is
  93. *much* confusion over the terminology that's used - not only by the
  94. media, but us, the computer users/professionals.  Developing a clearly
  95. defined set of terms and making everyone understand and use them would
  96. obviously be great, but would prove to be logistically impossible.  If
  97. we're all careful in our use of the terminology, and we even
  98. explicitly define what we mean whenever using terms that could be
  99. misconstrued, then perhaps we could try to eliminate *some* of the
  100. confusion.  Maybe it would be best to refrain from using such terms as
  101. "virulent", "benign", "virus", etc.?  Suggestions?]
  102.  
  103. ------------------------------
  104.  
  105. Date: Tue, 31 Jan 89 11:39:52 PST
  106. From:     PJS%naif.JPL.NASA.GOV@Hamlet.Bitnet
  107. Subject: Re: Origin of the term `virus'
  108.  
  109. I remember 8 years ago coming across the term `worm' for the first
  110. time: it was a program (developed at Xerox, I believe) that soaked up
  111. spare cpu cycles on networked machines to perform some lengthy,
  112. non-critical task (disk defragmentation or computing pi); there was no
  113. derogatory connotation.  Around the same time I read a book, "The
  114. Adolescence of P-1" (forget the author) about a program that took off
  115. across the network in much the same was as the RTM worm, although this
  116. one became sentient and altered technical specs for power supplies at
  117. IBM so that it could turn itself on, survive IPLs, etc, when the
  118. service rep installed the mod.
  119.  
  120. Peter Scott (pjs@naif.jpl.nasa.gov)
  121.  
  122. ------------------------------
  123.  
  124. Date:     Tue, 31 Jan 89 12:26:33 PST
  125. From:     <SPOCK@CALSTATE.BITNET>  (Commander Spock)
  126. Subject:  Virus epidemics.  Is the hype too much?
  127.  
  128. I just wanted to throw up an interesting idea that other developers
  129. and myself have been talking about for the last few weeks.
  130.  
  131. Our group theorized about the recent virus epidemics that are
  132. currently spreading around for both IBM as well as Macintosh
  133. computers.  Theory: there is big money (currently) for writing
  134. ATNI-VIRUS software to "protect" users against the nasty 'ol viri,
  135. right?  How do we know (users and developers alike) that these
  136. software makers of ANTI-VIRUS programs are not the true culprits
  137. behind the distribution (initially or re-distributed) of the various
  138. viri that's been creating havoc for the rest of the world (those
  139. affected).  I admit though, it's jumping to conclusions.  But has
  140. anyone else considered this possibility?  How would we know if our
  141. software is "safe" anymore?  The problem is, we cannot.
  142.  
  143. Pleaase note that I did not infer *ANY* organizational names of any
  144. nature, just merely threw up the possibility that we may be cutting
  145. our throats by attempting to protect ourselves.  Paranoia is the
  146. largest factor that causes viri to be passed around.  Fear of
  147. contamination, fear of destruction; all of this creates a unique blend
  148. of craziness.
  149.  
  150. Think it over before you purchase your next software package that
  151. guarantees that it's "safe" of any bugs or viri.
  152.  
  153. Robert S. Radvanovsky
  154. California Polytechnic University
  155. Pomona, California
  156.  
  157. P.S.  I will be willing to discuss this with those who feel that this
  158.       viri epidemic has gone a bit out of hand.  Should you feel that you
  159.       would like to contact me, please send appropriate mailings to:
  160.  
  161.          spock%calstate.bitnet@cunyvm.cuny.edu  <- Internet
  162.          spock@calstate.bitnet                  <- BITNET
  163.  
  164.       I've finally found out what our correct addresses are.  Mind
  165.       you, the views expressed here are "theories", nothing more.
  166.  
  167. ------------------------------
  168.  
  169. Date: Wed, 1 Feb 89 07:58:18 est
  170. From: ubu!luken@lehi3b15.csee.lehigh.edu
  171. Subject: Categorizing viruses
  172.  
  173. A while back (October 31, 1988 in log file VIRUS-L LOG8810E), Len
  174. Levine (len@EVAX.MILW.WISC.EDU) suggested denoting viruses which make
  175. use of features in an operating system as "Feature Exploiting
  176. Viruses", and viruses which make use of bugs as "Error Exploiting
  177. Viruses".  I think that it could be a good idea to classify viruses in
  178. a manner such as this.  However, I would like to expand on Professor
  179. Levine's idea a bit, if I may; viruses which use hardware (I use the
  180. term "hardware" very loosely - meaning anything which bypasses the
  181. operating system, including the BIOS) to propagate should be
  182. classified as "Hardware Exploiting Viruses".
  183.  
  184. Hardware Exploiting Viruses (HEVs) would thus be isolated to PCs and
  185. other (expletive deleted) computers that have no sort of hardware
  186. protection in the form of, for example, privileged commands for
  187. accessing i/o devices.  An example would be the Brain virus which uses
  188. ROM BIOS routines to write to the boot sector.  This would not work if
  189. the hardware restricted BIOS/hardware access to the privileged
  190. instructions (callable only by the operating system), assuming the OS
  191. is functioning properly.  These viruses could be stopped by adopting
  192. computer architectures which provide such hardware security.
  193.  
  194. Error Exploiting Viruses (EEVs) would be caused by (presumably) bugs
  195. in the operating system, such as undocumented system calls or even
  196. documented system calls which perform in an unexpected (by the
  197. manufacturer) manner.  A hypothetical example here might be a system
  198. call to write to disk which, when given "appropriate" parameters,
  199. allows the calling routine to write to the boot sector due to a
  200. programming error in the call.  These viruses would probably be the
  201. toughest of the three to stop since the bugs would generally only
  202. become evident when programs like the Internet Worm bring them to
  203. light.  The Internet Worm is a non-hypothetical example of an EEV.
  204. Extensive (read: costly) quality control in the form of testing could
  205. reduce the instances of EEVs.
  206.  
  207. Finally, Feature Exploiting Viruses (FEVs) would take advantage of
  208. procedural shortcomings such as lax usage of file read/write
  209. permissions on a system which would allow data to move from one
  210. filespace to another.  Such a virus could propagate even on a system
  211. which has the potential for neither HEVs nor EEVs.  Rather, it would
  212. be up to the system administration to establish proper operating
  213. procedures, such as file permissions.  An example of an FEV is the
  214. Lehigh Virus, which made use of MS-DOS operating system calls (INT
  215. 21H) to attach itself to COMMAND.COM files; this could be prevented by
  216. using the MS-DOS file attribute of READ-ONLY.
  217.  
  218. It would, of course, be possible for a virus to be made up of a
  219. combination of HEV, EEV, and FEV code.  The Internet Worm, for
  220. example, used several attack methods (sendmail bug, finger bug, etc.);
  221. it could well have been the case that these attack methods each fell
  222. into different categories.  The Lehigh Virus could also fall into more
  223. than one category since it used MS-DOS to propagate, but used a lower
  224. level (Absolute Disk Write) routine to destroy disks.
  225.  
  226. Why bother with categorizing viruses?  To learn more about them and to
  227. be able to disseminate information (fixes, etc.) effectively.  Of
  228. course, that's just my opinion...  Anybody have anything to add or
  229. change?
  230.  
  231. Ken van Wyk
  232.  
  233. ------------------------------
  234.  
  235. End of VIRUS-L Digest
  236. *********************
  237. Downloaded From P-80 International Information Systems 304-744-2253
  238.