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

  1. VIRUS-L Digest             Thursday, 2 Mar 1989         Volume 2 : Issue 57
  2.  
  3. Today's Topics:
  4. Viruses and System Security (a story)
  5. UofU infestation?
  6. Why people write viruses...
  7. FluShot+ 1.51 (PC)
  8. Re: More Info on definitions
  9. Lab Procedures
  10. Re: Closed virus list proposal
  11. Virus psychology information
  12. Flushot+ 1.51 question (PC)
  13.  
  14. ---------------------------------------------------------------------------
  15.  
  16. Date:         Fri, 3 Feb 89 04:00:00 EST
  17. Sender:       SECURITY Digest <SECURITY@PYRITE.RUTGERS.EDU>
  18. From:         AMSTerDamn System <R746RZ02@VB.CC.CMU.EDU>
  19. Subject:      Viruses and System Security (a story)
  20.  
  21. [Ed. reprinted from SECURITY Digest]
  22.  
  23. The following story was posted in news.sysadmin recently.
  24.  
  25. The more things change, the more they stay the same...
  26.  
  27. Back in the mid-1970s, several of the system support staff at Motorola
  28. (I believe it was) discovered a relatively simple way to crack system
  29. security on the Xerox CP-V timesharing system (or it may have been
  30. CP-V's predecessor UTS).  Through a simple programming strategy, it was
  31. possible for a user program to trick the system into running a portion
  32. of the program in "master mode" (supervisor state), in which memory
  33. protection does not apply.  The program could then poke a large value
  34. into its "privilege level" byte (normally write-protected) and could
  35. then proceed to bypass all levels of security within the file-management
  36. system, patch the system monitor, and do numerous other interesting
  37. things.  In short, the barn door was wide open.
  38.  
  39. Motorola quite properly reported this problem to XEROX via an official
  40. "level 1 SIDR" (a bug report with a perceived urgency of "needs to be
  41. fixed yesterday").  Because the text of each SIDR was entered into a
  42. database that could be viewed by quite a number of people, Motorola
  43. followed the approved procedure: they simply reported the problem as
  44. "Security SIDR", and attached all of the necessary documentation,
  45. ways-to-reproduce, etc. separately.
  46.  
  47. Xerox apparently sat on the problem... they either didn't acknowledge
  48. the severity of the problem, or didn't assign the necessary
  49. operating-system-staff resources to develop and distribute an official
  50. patch.
  51.  
  52. Time passed (months, as I recall).  The Motorola guys pestered their
  53. Xerox field-support rep, to no avail.  Finally they decided to take
  54. Direct Action, to demonstrate to Xerox management just how easily the
  55. system could be cracked, and just how thoroughly the system security
  56. systems could be subverted.
  57.  
  58. They dug around through the operating-system listings, and devised a
  59. thoroughly devilish set of patches.  These patches were then
  60. incorporated into a pair of programs called Robin Hood and Friar Tuck.
  61. Robin Hood and Friar Tuck were designed to run as "ghost jobs" (daemons,
  62. in Unix terminology);  they would use the existing loophole to subvert
  63. system security, install the necessary patches, and then keep an eye on
  64. one another's statuses in order to keep the system operator (in effect,
  65. the superuser) from aborting them.
  66.  
  67. So... one day, the system operator on the main CP-V software-development
  68. system in El Segundo was surprised by a number of unusual phenomena.
  69. These included the following (as I recall... it's been a while since I
  70. heard the story):
  71.  
  72. - -  Tape drives would rewind and dismount their tapes in the middle of a
  73.    job.
  74.  
  75. - -  Disk drives would seek back&forth so rapidly that they'd attempt to
  76.    walk across the floor.
  77.  
  78. - -  The card-punch output device would occasionally start up of itself
  79.    and punch a "lace card" (every hole punched).  These would usually
  80.    jam in the punch.
  81.  
  82. - -  The console would print snide and insulting messages from Robin Hood
  83.    to Friar Tuck, or vice versa.
  84.  
  85. - -  The Xerox card reader had two output stackers;  it could be
  86.    instructed to stack into A, stack into B, or stack into A unless a
  87.    card was unreadable, in which case the bad card was placed into
  88.    stacker B.  One of the patches installed by the ghosts added some
  89.    code to the card-reader driver... after reading a card, it would flip
  90.    over to the opposite stacker.  As a result, card decks would divide
  91.    themselves in half when they were read, leaving the operator to
  92.    recollate them manually.
  93.  
  94. I believe that there were some other effects produced, as well.
  95.  
  96. Naturally, the operator called in the operating-system developers.  They
  97. found the bandit ghost jobs running, and X'ed them... and were once
  98. again surprised.  When Robin Hood was X'ed, the following sequence of
  99. events took place:
  100.  
  101.   !X id1
  102.  
  103.   id1:   Friar Tuck... I am under attack!  Pray save me!  (Robin Hood)
  104.   id1: Off (aborted)
  105.  
  106.   id2: Fear not, friend Robin!  I shall rout the Sheriff of Nottingham's men!
  107.  
  108.   id3: Thank you, my good fellow! (Robin)
  109.  
  110. Each ghost-job would detect the fact that the other had been killed, and
  111. would start a new copy of the recently-slain program within a few
  112. milliseconds.  The only way to kill both ghosts was to kill them
  113. simultaneously (very difficult) or to deliberately crash the system.
  114.  
  115. Finally, the system programmers did the latter... only to find that the
  116. bandits appeared once again when the system rebooted!  It turned out
  117. that these two programs had patched the boot-time image (the /vmunix
  118. file, in Unix terms) and had added themselves to the list of programs
  119. that were to be started at boot time...
  120.  
  121. The Robin Hood and Friar Tuck ghosts were finally eradicated when the
  122. system staff rebooted the system from a clean boot-tape and reinstalled
  123. the monitor.  Not long thereafter, Xerox released a patch for this
  124. problem.
  125.  
  126. I believe that Xerox filed a complaint with Motorola's management about
  127. the merry-prankster actions of the two employees in question.  To the
  128. best of my knowledge, no serious disciplinary action was taken against
  129. either of these guys.
  130.  
  131. Several years later, both of the perpetrators were hired by Honeywell,
  132. which had purchased the rights to CP-V after Xerox pulled out of the
  133. mainframe business.  Both of them made serious and substantial
  134. contributions to the Honeywell CP-6 operating system development effort.
  135. Robin Hood (Dan Holle) did much of the development of the PL-6
  136. system-programming language compiler; Friar Tuck (John Gabler) was one
  137. of the chief communications-software gurus for several years.  They're
  138. both alive and well, and living in LA (Dan) and Orange County (John).
  139. Both are among the more brilliant people I've had the pleasure of
  140. working with.
  141.  
  142. Disclaimers: it has been quite a while since I heard the details of how
  143. this all went down, so some of the details above are almost certainly
  144. wrong.  I shared an apartment with John Gabler for several years, and he
  145. was my Best Man when I married back in '86... so I'm somewhat
  146. predisposed to believe his version of the events that occurred.
  147.  
  148. - --
  149. Dave Platt
  150.   Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303
  151.  
  152. ------------------------------
  153.  
  154. Date:    Sat, 25 Feb 89 00:15 CST
  155. From:    Gordon Meyer <TK0GRM1@NIU.BITNET>
  156. Subject: UofU infestation?
  157.  
  158. I was speaking with my mother tonight and she said that the local news
  159. had a story about a recent virus infestation at the University of
  160. Utah.  She couldn't recall any of the details.  Any VIRUS-L readers
  161. know of this?
  162. - -=->G<-=-
  163. Gordon R. Meyer, Dept of Sociology, Northern Illinois University.
  164. GEnie: GRMEYER  CIS: 72307,1502  Phone: (815) 753-0365
  165. Bitnet: tee-kay-zero-gee-are-em-one at enn-eye-you
  166. Disclaimer: Grad students don't need disclaimers!
  167.             I'll have an opinion when I get my degree.
  168. - --- BE YE NOT LOST AMONG PRECEPTS OF ORDER... (book of Uterus) ---
  169.  
  170. ------------------------------
  171.  
  172. Date: 25 February 1989 14:26:00 CST
  173. From: "Michael J. Steiner  " <U23405@UICVM.BITNET>
  174. Subject:  Why people write viruses...
  175.  
  176. After listening to the VIRUS-L discussion for a few months, it finally
  177. hit me that maybe some people write viruses because... (well, let me
  178. explain it in detail):
  179.  
  180. The people who write viruses are usually (if not always) people who
  181. are very knowledgeable about computers. Being very knowledgeable about
  182. computers, these people might look down upon novices, and might write
  183. a virus, which would mostly affect novices (who sometimes barely even
  184. know that viruses exist) while not affecting other experts (who are
  185. aware of viruses and know the necessary precautions to avoid
  186. infection). Thus, a virus-writer can get pleasure out of
  187. confusing/disrupting the novices' efforts at learning about computers.
  188. (I hope I explained this clearly enough.)
  189.  
  190. Any replies, comments, flames, accepted.
  191.  
  192. Disclaimer #1:  I am an undergrad. :-)         Michael Steiner
  193. Disclaimer #2:  Don't take this note           Email: U23405@UICVM.BITNET
  194.                 personally.
  195.  
  196. ------------------------------
  197.  
  198. Date:     Sat, 25 Feb 89 22:19 EDT
  199. From:     Llamas are bigger than frogs <PCOEN@DRUNIVAC.BITNET>
  200. Subject:  FluShot+ 1.51 (PC)
  201.  
  202. I've just downloaded FluShot+ 1.51 from the RAMnet BBS in NYC and I've
  203. noticed that I'm having the same problem with it that I had with
  204. version 1.4......it gives me bad checksums on my command.com,
  205. ibmbio.com and ibmdos.com.  However, all 3 files are okay.  Is it
  206. looking for the "True Blue" versions of these files?  I have a Zenith
  207. z-157 with MS-DOS 3.2.  Has anyone else had this problem?  I glanced
  208. in the manual, there didn't seem to be a way to alter what it's
  209. looking for (hardly suprising...that would be a major hole, in all
  210. likelyhood....).  Any tips/advice would be appreciated.
  211.  
  212. Paul Coen, Drew University         Bitnet:  PCOEN@DRUNIVAC, PCOEN@DREW
  213.  
  214. ------------------------------
  215.  
  216. Date:     Mon, 27 Feb 89 09:51:53 GMT
  217. From:     UA0095@SYSB.SALFORD.AC.UK
  218. Subject:  Re: More Info on definitions
  219.  
  220. Hi there folks, Me again.
  221.  
  222. Many thanks for the replies to my plea for help about the definitions.
  223. (comments etc are still welcome).  I was suprised to find that out
  224. those who replied, who obviously consider themselves knowledgeable
  225. about the subject, their definitions did all slightly differ.  Below
  226. is a summary of the replies I got, hopefully they are as correct as
  227. the subject will allow (due to it's non-descript nature).  I would
  228. gratefully receive anything that you would like to add.
  229.  
  230. TROJAN HORSE
  231.  
  232. A Trojan horse is a program that does something that the programmer
  233. intended it to, but the user did not.  (And, generally, that the
  234. user would not have approved of had he/she known about it.)
  235.  
  236. A trojan horse is a program which is concealed inside another, for the
  237. purpose of executing inside another user's protection boundary (on his
  238. PC, or in a job he runs on a system, or in his virtual machine in VM).
  239.  
  240. ( The term also applies to programs which masquerade as others, as
  241. might a password-stealing program which emulates a legitimate system,
  242. and thereby fools a user into entering a password, which the TH then
  243. "steals".  A compiler which, when executed, copies an unrelated file
  244. to the compilerdiskette would be an example, too. )  Is this strictly
  245. true?  I thought a Trojan Horse actually did something also.
  246.  
  247.  
  248. WORM
  249.  
  250. A worm is a program which replicates itself through a network,
  251. generally with the goal of consuming more system resources than would
  252. be otherwise available to it.
  253.  
  254.  
  255. VIRUS
  256.  
  257. A virus is, to quote Fred Cohen, "a program that can 'infect' other
  258. programs by modifying them to include a possibly evolved copy of
  259. itself".
  260.  
  261. A virus is a program which attaches itself to other programs (or
  262. possibly to a disk, although that is a minor distinction in my view;
  263. it is then attaching itself to the boot record, which is a program)
  264. and when it gets control, attaches itself to more programs.  It may
  265. also take some action, possibly at random or timed, in addition to the
  266. replication.
  267.  
  268. Well that's it, who's Fred Cohen?
  269.  
  270. Thanks in advance ( we should abbreviate that, in the time honoured
  271. tradition, like the best things are in computing to "T.I.A."  what do
  272. you think?)
  273.  
  274.                                         Steve.
  275.  
  276. ------------------------------
  277.  
  278. Date:         Mon, 27 Feb 89 08:34:42 MST
  279. From:         Jim Howard <KGJHH@ASUACAD.BITNET>
  280. Subject:      Lab Procedures
  281.  
  282. We have a number of IBM-PC networks with read only file servers. We
  283. have never had a virus problem there in their 5 years of existance. We
  284. can boot from the network due to boot proms on our network interface
  285. cards.  Our Appletalk/Mac labs are another story. We have to go thru
  286. the disk washing procedure like many others here have described. We
  287. would like to have a network interface card with a boot prom on our
  288. Mac's also.  We would need a faster interface such as ethernet, but
  289. the extra speed would benefit the customers as well as give everyone
  290. some security from infection. We have been showing every Apple person
  291. we get on campus how well our IBM labs work and saying we need the
  292. ability to boot from Mac networks. Most Mac II ethernet cards have an
  293. empty PROM socket and there is a mention of optional Prom functions in
  294. the Apple adapters documentation. A scheme (or modification to MAC OS)
  295. would have to be developed to allow people to customize their own
  296. screens, desktops, etc.  as they are accustomed to. Of course the very
  297. nature of the Mac OS and its modification of files (resources, etc) is
  298. tailr made for the infection process of viruses.  Regardless the
  299. ability to be able to boot from a network file server is very high on
  300. our wish list from Apple. It would be well worth the additional cost
  301. of an ethernet card for every Mac.
  302.  
  303. ------------------------------
  304.  
  305. Date: Tue, 28 Feb 89 14:37:50 CST
  306. From: Kenneth W. Loafman <convex!loafman@a.cs.uiuc.edu>
  307. Subject: Re: Closed virus list proposal
  308.  
  309. I am against the formation of the list for a list of reasons:
  310.  
  311. 1) I have yet to see a 'live' virus of any description and I have
  312. downloaded and run probably 30Mb or more of PC software in the last
  313. year.  How do I know that this list will not be the basis for the
  314. creation of the first virus I will see?  How can I trust you any more
  315. than you can trust me?
  316.  
  317. 2) The information on how to 'protect' from viruses, if it is not to
  318. be commercial, will tell how to build the very viruses that they
  319. protect against.  How do I accept someone's word that the virus
  320. protection program someone is hawking for $100 is useful much less
  321. whether it is a valid program unless I know how it works?  If I know
  322. how it works, what's the advantage of the list?
  323.  
  324. 3) I do know how to build viruses.  What I'm looking for in this list
  325. is further information on what else can be done to protect against
  326. them.  I cannot get that information without being able to write them
  327. as well.  Item 1 above led me to the construction of a couple of test
  328. cases so I could check out a hardware solution to the problem using a
  329. hardware debugger.  >From the descriptions of the viruses on the PC so
  330. far, this solution should be complete, i.e. a software virus should
  331. not be able to get past hardware protection methods.  I'm still
  332. looking for a 'live' virus to try it out on.
  333.  
  334. 4) I _refuse_ to purchase commercial software for virus protection and
  335. may need all the informational help I can get.  Crime should not pay
  336. for anyone and we all need to band together to keep the virus scare
  337. from producing yet another market segment.  The formation of a private
  338. list fosters that market segment by keeping information secret.
  339.  
  340. Now before anyone accuses me of heresy, let me add another comment.
  341. If the list is formed, I need to be on it.  I do a great deal of
  342. collection and review of PC software for the North Texas PC Users
  343. Group and have valid need for the information that might be withheld
  344. if this list is formed without me.  A single virus that slips past the
  345. reviewers could fan out to several hundred people in a very short
  346. time.  That would be very bad news!
  347.  
  348. - -----
  349. Kenneth W. Loafman @ CONVEX Computer Corp, Dallas, Texas
  350. email:  {allegra,uiucdcs,ctvax}!convex!loafman
  351. phone:  (214) 952-0829
  352.  
  353. ------------------------------
  354.  
  355. Date:         Mon, 6 Feb 89 16:31:25 EST
  356. Sender:       SECURITY Digest <SECURITY@PYRITE.RUTGERS.EDU>
  357. From:         FLORY <hxwy@VAX1.CIT.CORNELL.EDU>
  358. Subject:      Virus psychology information
  359.  
  360. In response to "Commander Spock"'s question about sources of
  361. information on why people write virus's, I suggest he look at a few
  362. recent magazine articles (I really doubt any books have been on the
  363. topic as of yet)
  364.  
  365. In the Summer issue of 2600 magazine there is an article by "The
  366. Plague" called "How to Write a Virus: The Dark Side of Viruses".  He
  367. claims to have written a viruse called CyberAIDS which attacks the
  368. Apple II series, but besides his "qualifications" you can get a pretty
  369. good idea of the twisted kind of mind who enjoy this kind of thing
  370. (Mr. "Plague" claims to have no moral objections to trashing people's
  371. hard work) The article goes into the theory of virus writing (not
  372. system specific) A careful reading between the lines can provide a
  373. psycological outline of one kind of virus writer.
  374.  
  375. you can get a back issue of 2600 by writing to 2600 Magazine, PO Box
  376. 752, Middle Island, NY 11953-0752.
  377.  
  378. You also may want to look up the Winter 1988 issue of "High Frontiers
  379. Reality Hackers" for an article called "Cyber Terrorists / Viral
  380. Hitman" Reading it between the lines also reveals a lot about the type
  381. of person who would voluntarily release a virus.
  382.  
  383. David James Flory
  384.  
  385. PS I don't support, condone, or agree with any of these authors, I am
  386. just bringing them up for a view of why people would write these
  387. things.
  388.  
  389. ------------------------------
  390.  
  391. Date:    Thu,  2 Mar 89 13:47 CET
  392. From:    "Jelle Uenk" <LETTXN@HLERUL2.BITNET>
  393. Subject: Flushot+ 1.51 question (PC)
  394.  
  395. I've used FluShot+ 1.51 now for two weeks, and I'm quite satisfied
  396. with it. I've noticed some strange behaviour when using PC-Tools (I
  397. believe its version 4.5 (?)). Even with FSP installed I'm able to
  398. rename, delete etc. the system files command.com, ibmbio.com and
  399. ibmdos.com. When I try to do the same with any other utility (and
  400. DEL/REN on the commandline too) FluShot behaves as expected: It warns
  401. about the action.  I'm wondering what I'm doing wrong with my setup of
  402. FSP+.  Or is PC-Tools using some very special method of writing to the
  403. harddisk? (It uses neither INT13 nor INT26 for the DEL/Rename, because
  404. if I EDIT (with PCTOOLS) COMMAND.COM FluShot gets triggerd).
  405.  
  406. Can anyone give me some more information?
  407.  
  408. Jelle Uenk
  409. Student Assistent
  410. Leiden University - The Netherlands
  411.  
  412. ------------------------------
  413.  
  414. End of VIRUS-L Digest
  415. *********************
  416. Downloaded From P-80 International Information Systems 304-744-2253
  417.