home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / pc / virus / v01i016.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  15.6 KB  |  362 lines

  1. VIRUS-L Digest              Monday, 21 Nov 1988         Volume 1 : Issue 16
  2.  
  3. Today's Topics:
  4. "hacker" paper anncmnt
  5. CSI [who?] Standpoint on Internet worm
  6. Correction on previous posting (V1 I14)
  7. Nightline Transcript available
  8. RE: Letter to U.S. attorneys
  9. Re: Viruses doing hardware damage
  10. RE:Can virii cause hardware damage
  11. (1) Military virus targets; (2) voting fraud by computer.
  12.  
  13. ---------------------------------------------------------------------------
  14.  
  15. Date:    Mon, 21 Nov 88 02:19 CST
  16. From:    Gordon Meyer  <TK0GRM1@NIU>
  17. Subject: "hacker" paper anncmnt
  18.  
  19. I've been enjoying the on-going debates about just who and what
  20. hackers are.  I've devoted quite a bit of time and energy studying
  21. this question and I thought I'd make some of the results available to
  22. those of you that might be interested.
  23.  
  24. I am in the process of writing a Master's thesis on the social
  25. organization of the computer underground.  It's a participant
  26. observation/ethnographic project, so the conclusions I draw and the
  27. illustrations I present are taken from the hackers, phreakers, and
  28. pirates themselves....not the media and other usual sources.
  29.  
  30. The paper I have available (about 10 pages) is a revision of a
  31. work-in-progress presentation made earlier this month.  Titled
  32. "Hackers, Phreakers, and Pirates: The Semantics of the Computer
  33. Underground"<{ it discusses the use of such terms and offers some
  34. classification guidelines in order to help resolve the "anyone with a
  35. modem is a hacker" finger-pointing that often occurs.
  36.  
  37. If you would like a copy please respond directly to me, not this
  38. list.
  39. Your feedback and criticisms are most welcome as well.
  40. - -=->G<-=-
  41.  
  42. PS: This note is being cross posted to Virus-l and Ethics-l.
  43.  
  44. Gordon R. Meyer, Dept of Sociology, Northern Illinois University.
  45. GEnie: GRMEYER  CIS: 72307,1502  Phone: (815) 753-0365
  46. Bitnet: tee-kay-zero-gee-are-em-one at enn-eye-you
  47. Disclaimer: Grad students don't need disclaimers!
  48.             I'll have an opinion when I get my degree.
  49. - --- BE YE NOT LOST AMONG PRECEPTS OF ORDER... (book of Uterus) ---
  50.  
  51. ------------------------------
  52.  
  53. Date: Mon, 21 Nov 88 10:15:36 EST
  54. From: roskos@ida.org (Eric Roskos)
  55. Subject: CSI [who?] Standpoint on Internet worm
  56.  
  57. > In the
  58. > wake of the recent attack of the ARPANET virus, it was necessary
  59. > to close down our usual computer operations and devote _______
  60. > hours of debugging and testing before we could safely resume
  61. > normal operation.
  62. >
  63. > This represents a significant interruption of our business, and
  64. > deprived us of an estimated $_______ of employee time.
  65.  
  66. This past Saturday evening's "Communications World" broadcast on the
  67. Voice of America devoted a significant amount of time to discussing
  68. the Internet virus.
  69.  
  70. An interesting point, made by an AT&T researcher who was interviewed
  71. by VOA, was that the ARPAnet began as a research network (note the "R"
  72. in ARPA), which unfortunately many people had become dependent on
  73. despite the fact that its software was not designed for this type of
  74. usage.  This is, in fact, why the ARPAnet per se is being
  75. discontinued, to be replaced by other networks; to quote from the
  76. bulletin "Death of the ARPAnet and Other Paranoia," published by the
  77. management of the ARPAnet,
  78.  
  79. > In addition to being heavily loaded, the ARPANET is no longer able to
  80. > support its other prime function, that of a research base.  To conduct
  81. > any kind of experiment on the ARPANET causes too much service
  82. > disruption to the community.
  83.  
  84. The solution to this, the authors (Mark Pullen and Brian Boesch of
  85. DARPA) say, is "to eliminate the source of the problem" by
  86. "outgrowing" the current network, replacing it with an "experimental"
  87. network, funded by DARPA to promote network research, and an
  88. "operational" network, paid for by the users and run by a contractor.
  89. [Note: the complete text of this bulletin was posted by its authors to
  90. the Usenet's TCP-IP newsgroup a few months ago.]  In fact, if one
  91. carefully reads the regulations for use of the ARPAnet, and then
  92. considers how the ARPAnet is used in practice, it is much easier to
  93. see why the above recommended letter is simplistic.
  94.  
  95. Given this fact, and the fact that the author of the virus clearly did
  96. not intend to do damage, and in fact was successful at causing a
  97. service degradation only at sites which had not corrected known
  98. security problems in their software, the proposed actions seem
  99. somewhat extreme; it seems as if the suspected author of the virus is
  100. being made a "scapegoat" for the unknown authors of the many
  101. intentionally harmful and malicious viruses.
  102.  
  103. This is not intended to advocate the writing of such viruses.
  104. However, considering especially that all the blame has fallen on the
  105. virus writer, and seemingly none on the programmer who coded the "back
  106. door" into Sendmail -- and which could be and perhaps may have been
  107. used to gain access to systems many times before this virus publicized
  108. its existence -- the recommended letter seems somewhat extreme.
  109. Overreaction, rather than straightforward correction of the technical
  110. problems involved, might have the undesirable side effect of denying
  111. beneficial research environments and communication provided to the
  112. research community via the ARPAnet, of which the VIRUS-L mailing list
  113. is just one example.
  114.  
  115. DISCLAIMERS: The above is my personal opinion, and does not
  116. necessarily reflect the opinion of my employer nor those with whom my
  117. employer does business.  The comments describing the ARPAnet and its
  118. research function are based on my current understanding of its role in
  119. the research community, and do not necessarily reflect the position of
  120. DARPA or the management of the ARPAnet.
  121.  
  122. ------------------------------
  123.  
  124. Date:     21 Nov 1988 11:09:29-WET
  125. From:     Julian Daley <jdaley@UXG.UMDS.LON.AC.UK>
  126. Subject:  Correction on previous posting (V1 I14)
  127.  
  128. SORRY !  That message was posted to the WRONG LIST.
  129. I am _very_ embarressed 8-(
  130. If anybody IS interested in chaos try the frac-l list
  131. which is held by the listserv @ gitvm1  ( where I was
  132. trying to send the last message !)
  133. Many apologies (the worm must have got to my brain),
  134. Julian.
  135.  
  136. [Ed. My apologies also, for letting it slip by...]
  137.  
  138. ------------------------------
  139.  
  140. Date:         Mon, 21 Nov 88 10:55:55 EST
  141. From:         Scott Earley <SCOTT@BITNIC>
  142. Subject:      Nightline Transcript available
  143.  
  144. After reading Doug Hunt's msg about Koppel I made an investigation
  145. worth sharing.  Permission was granted by a telemarketer for this:
  146.  
  147. Show title:  Computer Viruses
  148. Air Date:    Nov 10, 1988
  149.  
  150. Send $3.00 to Nightline Broadcasts
  151.               267 Broadway
  152.               NY, NY 10007
  153.  
  154. or phone 212 227-7323 for credit card orders
  155.  
  156. (Doug, I had them verify this date TWICE :-)
  157.  
  158. [Ed. Thanks for the info, Scott; I wonder whether they have
  159. transcripts available on 5 1/4 " disk...  :-) ]
  160.  
  161. ------------------------------
  162.  
  163. Date: Mon, 21 Nov 88 12:34 EST
  164. From: Chris Bracy <KCABRAC@VAX1.CC.LEHIGH.EDU>
  165. Subject: RE: Letter to U.S. attorneys
  166.  
  167. >       1. Send a letter to your local U.S. attorneys recommending
  168. >    that the ARPANET virus situation be prosecuted to the full extent
  169. >    of the law.  It may even be appropriate that your organization
  170. >    take some form of independent legal action in this case; and,
  171. >
  172. >       2. Send a letter to your state and federal legislators
  173. >    requesting that they aggressively pursue the development of
  174. >    effective computer crime legislation.  You might even offer to
  175. >    help evaluate drafts of pending bills.  Attached are sample of
  176. >    letters you may wish to use as models to get this message to your
  177. >    local U.S. attorneys and your legislators.
  178.  
  179. This will insure that only those people with actual criminal intent
  180. will write a virus.  And that the code is better written so it cant be
  181. found as easily.
  182.  
  183. Yes damage was done.  Many man hours of work was lost.  But if you
  184. think about it, it could have been much, much worse.  If harm was
  185. intended, it was very easy to do.  But the intent was obviously not
  186. harm.
  187.  
  188. This just showed us that we have to be more careful.  We can't
  189. legislate computer security, we have to program it in.
  190.  
  191. Chris.
  192.  
  193.  
  194. *==============================*======================================*
  195. |       Chris A. Bracy         |         Student Consultant           |
  196. |       (215) 758-4141         |  Lehigh University Computing Center  |
  197. |  Kcabrac@Vax1.cc.Lehigh.Edu  |    Fairchild Martindale Bldg.  8B    |
  198. |   Kcabrac@LehiCDC1.Bitnet    |           Lehigh University          |
  199. |       CAB4@Lehigh.Bitnet     |          Bethlehem, PA 18015         |
  200. *==============================*======================================*
  201.  
  202. ------------------------------
  203.  
  204. Date:         Mon, 21 Nov 88 12:30:28 EST
  205. From:         Jim McIntosh <MCINTOSH%AUVM.BITNET@IBM1.CC.Lehigh.Edu>
  206. Subject:      Re: Viruses doing hardware damage
  207.  
  208. >     I believe I've read somewhere that viruses can cause hardware
  209. >problems, like drives to fail.  Does anyone know what the specific
  210. >problem with the drives could be if a virus would do this(cause one to
  211. >fail.)?
  212.  
  213. If someone could get damaging code executed on my machine it could
  214. damage data stored on hardware in such a way as to appear to be a
  215. hardware error.  I have all VM priviledge classes, and can link to
  216. fullpack minidisks that include system areas.  A good virus could
  217. issue the DIRECT command, thereby preventing anyone from logging on,
  218. and then issue some links and then do some physical I/O's to wipe out
  219. areas like the VTOC on our disk packs.
  220.  
  221. We would get disk errors (NO RECORD FOUND, etc) which could appear to
  222. be hardware errors, and if we tried to re-IPL we would find that the
  223. system would be dead.  It might take some time to discover that that
  224. it was a virus, and not a disk controller error (for example).
  225.  
  226. ------------------------------
  227.  
  228. Date:     Mon, 21 Nov 88 13:14 EST
  229. From:     <ACS045@GMUVAX> Steve Okay
  230. Subject:  RE:Can virii cause hardware damage
  231.  
  232. >From:     Ain't no livin' in a Perfect World. <KUMMER@XAVIER>
  233. >Subject:  Can viruses cause hardware damage?
  234. >
  235. >     I believe I've read somewhere that viruses can cause hardware
  236. >problems, like drives to fail.  Does anyone know what the specific
  237. >problem with the drives could be if a virus would do this(cause one to
  238. >fail.)?
  239. >Tom Kummer
  240.  
  241. This has been kicked around on here before and I believe that the
  242. general consensus was "yes", but in a sort of roundabout way.  That is
  243. to say, they can' t damage hardware directly, but by some rather
  244. clever programming.  Also I don't recall any of the affirmative
  245. messages mentioning anything about a virus program doing the damage.
  246. Most, if I recall correctly, were just singular, albeit still
  247. destructive, programmings.  To wit are several notices below from
  248. VIRUS-L of the recent past.
  249.  
  250. #1::
  251. From:         "JOHN D. WATKINS" <WATKINS@UCRVMS>
  252. Subject:      kill that drive!
  253.  
  254.   On the subject of damaging disk drives, a couple months ago I read
  255. (I think in Computers & Society Digest) about a prank you could play
  256. with drives; you figure out a good resonant frequency for the drive,
  257. then make the head(s) seek at just that rate.  The drive starts
  258. vibrating (relatively) violently, enough so that it creeps across the
  259. floor, possibly unplugging itself and certainly puzzling the operators
  260. in the morning!
  261.   I believe that this referred to mainframe drives, but it has
  262. interesting possibilities for micros as well; if you could make a
  263. drive vibrate for long enough you might be able to throw it out of
  264. alignment or something evil like that...
  265.  
  266.    Kevin
  267.  
  268. #2:
  269. From:         GREENY <MISS026@ECNCDC>
  270. Subject:      even *MORE* on hardware damage
  271.  
  272. All this talk of "programs" causing damage to hardware has caused a
  273. few of the ole cobwebs to clear out of the history section of my brain
  274. which caused a story that I heard a long long time ago in a CS101
  275. class to surface..
  276.  
  277. "...It seems that a programmer who delighted in taking excessively
  278. long lunch hours discovered a way to shut down the computer for hours
  279. at a time.  It happened that the programmer -- in those days also
  280. being somewhat of an Electrical Engineer -- discovered exactly which
  281. MAGNETIC CORE was closest to the High-Temp shutdown sensor, and wrote
  282. a program which continously wrote an alternating pattern of binary 0's
  283. and 1's to *THE* core, until it got hot enough to trigger the
  284. High-Temp shutdown sensor.  The sensor, being decieved into thinking
  285. that the entire machine was overheating, promptly shut it down"
  286.  
  287.  ...An oldie, but a goodie...
  288.  
  289. Bye for now but not for long
  290. Greeny
  291.  
  292. Bitnet: miss026@ecncdc
  293. Internet: miss026%ecncdc.bitnet@cunyvm.cuny.edu
  294. Disclaimer: If you happen to still have some core memory machines
  295.    being used and you pull this trick -- forget where you read this!:->
  296.  
  297. - -----------------------End Appended Messages------------------------------
  298.  
  299. Hope that Helps.....
  300. - ---Steve
  301. - -------------
  302. Steve Okay/ACS045@GMUVAX.BITNET/acs045@gmuvax2.gmu.edu/CSR032 on The Source
  303.  
  304.                 "Too Busy to think of a clever and witty Disclaimer"
  305.  
  306. ------------------------------
  307.  
  308. Date:     Mon, 21 Nov 88 08:44 EDT
  309. From:     <J_CERNY@UNHH> Jim Cerny
  310. Subject:  (1) Military virus targets; (2) voting fraud by computer.
  311.  
  312. Here are a couple of thoughts after virus/worm events of the last
  313. couple of weeks.  BTW, I much appreciate the "reprinting" of selected
  314. items from RISKS and other lists that contain items of interest to
  315. VIRUS-L subscribers because I already attempt to scan too many list as
  316. it is.
  317.  
  318. Military virus targets.
  319. - ----------------------
  320. Even if the recent virus, or some other virus, did hit some military
  321. systems, I doubt that we would know it.  Experience of the last
  322. decades shows that the federal government would go to great lengths to
  323. cover up such a fact.  It would be classified before you could press
  324. RETURN!
  325.  
  326. Another thought.  If I worked for a technologically-advanced, hostile
  327. country and wanted to do evil things to the US military capability, it
  328. seems to me that very-early-on in a brainstorming session I'd have the
  329. idea of building my virus/worm/whatever-you-call-it into the actual
  330. chips that would be manufactured into the computer.  I believe the
  331. military uses chips from the usual Asian source countries.  If you
  332. say, nah, this could not happen, consider the problems being caused by
  333. counterfeit bolts.  Asian suppliers are flooding the US with
  334. low-performance bolts made to look like high performance bolts and
  335. some of these have been built into military equipment.  Now, it seems
  336. to me that the "correctness" of a bolt is relatively easy to do
  337. testing on, compared to a chip!
  338.  
  339. Voting fraud by computer.
  340. - ------------------------
  341. Coincident with all the uproar over the recent Unix-penetrating virus,
  342. there was an article published in The New Yorker, November 7, 1988, by
  343. Ronnie Dugger, titled "Annals of Democracy: Voting by Computer."  The
  344. gist of the article is that computers are being used more and more to
  345. count votes, yet there are tremendous risks for rigging elections and
  346. that this strikes at the heart of our democracy.  In the long run I
  347. think this is a much more vital and important topic than the
  348. occasional virus that gets loose and generates great publicity. The
  349. vote rigging might not be done by a VIRUS, but I think this is a
  350. subject that may interest many VIRUS-L subscribers.  If this is
  351. discussed on RISKS, I'd appreciate it if a RISK subscriber would
  352. forward to me a copy of any such voter-fraud-by-computer comments.
  353.  
  354.   Jim Cerny, University Computing, University of New Hampshire
  355.   J_CERNY@UNHH  (BITNET)
  356.   .. uunet!unh!jwc   (UUCP)
  357.  
  358. ------------------------------
  359.  
  360. End of VIRUS-L Digest
  361. *********************
  362.