home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / misc / 4054 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  6.0 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!network.ucsd.edu!ucsbcsl!engrhub!harley
  2. From: harley@engrhub.ucsb.edu (Hahn)
  3. Newsgroups: comp.unix.misc
  4. Subject: Re: Daemons must never die
  5. Message-ID: <6526@ucsbcsl.ucsb.edu>
  6. Date: 5 Nov 92 08:36:02 GMT
  7. References: <1992Oct31.170040.25978@chance.gts.org> <Bx2Eqw.DF3@ns1.nodak.edu> <49215@shamash.cdc.com>
  8. Sender: news@ucsbcsl.ucsb.edu
  9. Lines: 117
  10.  
  11. In article <49215@shamash.cdc.com> alf@shamash.cdc.com (Alessandro Forghieri) writes:
  12. >
  13. >On the subject of never-dying daemons, I remember an interesting
  14. >discussion took place a few weeks back (maybe on comp.unix.wizards ?) on
  15. >Robin Hood-Friar TUck programs, on of whose purposes was to ensure that
  16. >the companion process would never die.
  17.  
  18. Here is the story from the Jargon file.
  19.  
  20. To ftp this file, connect to pit-manager.mit.edu and look
  21. in the /pub/jargon directory.
  22.  
  23. -- Harley Hahn
  24.  
  25. ----------
  26.  
  27.      Back in the mid-1970s, several of the system support staff at
  28.      Motorola discovered a relatively simple way to crack system
  29.      security on the Xerox CP-V timesharing system.  Through a simple
  30.      programming strategy, it was possible for a user program to trick
  31.      the system into running a portion of the program in `master mode'
  32.      (supervisor state), in which memory protection does not apply.  The
  33.      program could then poke a large value into its `privilege level'
  34.      byte (normally write-protected) and could then proceed to bypass
  35.      all levels of security within the file-management system, patch the
  36.      system monitor, and do numerous other interesting things.  In
  37.      short, the barn door was wide open.
  38.  
  39.      Motorola quite properly reported this problem to Xerox via an
  40.      official `level 1 SIDR' (a bug report with an intended urgency of
  41.      `needs to be fixed yesterday').  Because the text of each SIDR was
  42.      entered into a database that could be viewed by quite a number of
  43.      people, Motorola followed the approved procedure: they simply
  44.      reported the problem as `Security SIDR', and attached all of the
  45.      necessary documentation, ways-to-reproduce, etc.
  46.  
  47.      The CP-V people at Xerox sat on their thumbs; they either didn't
  48.      realize the severity of the problem, or didn't assign the necessary
  49.      operating-system-staff resources to develop and distribute an
  50.      official patch.
  51.  
  52.      Months passed.  The Motorola guys pestered their Xerox
  53.      field-support rep, to no avail.  Finally they decided to take
  54.      direct action, to demonstrate to Xerox management just how easily
  55.      the system could be cracked and just how thoroughly the security
  56.      safeguards could be subverted.
  57.  
  58.      They dug around in 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
  61.      Tuck'.  Robin Hood and Friar Tuck were designed to run as `ghost
  62.      jobs' (daemons, in UNIX terminology); they would use the existing
  63.      loophole to subvert system security, install the necessary patches,
  64.      and then keep an eye on one another's statuses in order to keep the
  65.      system operator (in effect, the superuser) from aborting them.
  66.  
  67.      One fine day, the system operator on the main CP-V software
  68.      development system in El Segundo was surprised by a number of
  69.      unusual phenomena.  These included the following:
  70.  
  71.         * Tape drives would rewind and dismount their tapes in the
  72.           middle of a job.
  73.         * Disk drives would seek back and forth so rapidly that they
  74.           would attempt to walk across the floor (see {walking drives}).
  75.         * The card-punch output device would occasionally start up of
  76.           itself and punch a {lace card}.  These would usually jam in
  77.           the punch.
  78.         * The console would print snide and insulting messages from
  79.           Robin Hood to Friar Tuck, or vice versa.
  80.         * The Xerox card reader had two output stackers; it could be
  81.           instructed to stack into A, stack into B, or stack into A
  82.           (unless a card was unreadable, in which case the bad card was
  83.           placed into stacker B).  One of the patches installed by the
  84.           ghosts added some code to the card-reader driver... after
  85.           reading a card, it would flip over to the opposite stacker.
  86.           As a result, card decks would divide themselves in half when
  87.           they were read, leaving the operator to recollate them
  88.           manually.
  89.  
  90.      Naturally, the operator called in the operating-system developers.
  91.      They found the bandit ghost jobs running, and X'ed them... and were
  92.      once again surprised.  When Robin Hood was X'ed, the following
  93.      sequence of events took place:
  94.  
  95.           !X id1
  96.  
  97.           id1: Friar Tuck... I am under attack!  Pray save me!
  98.           id1: Off (aborted)
  99.  
  100.           id2: Fear not, friend Robin!  I shall rout the Sheriff
  101.                of Nottingham's men!
  102.  
  103.           id1: Thank you, my good fellow!
  104.  
  105.      Each ghost-job would detect the fact that the other had been
  106.      killed, and would start a new copy of the recently slain program
  107.      within a few milliseconds.  The only way to kill both ghosts was to
  108.      kill them simultaneously (very difficult) or to deliberately crash
  109.      the system.
  110.  
  111.      Finally, the system programmers did the latter --- only to find
  112.      that the bandits appeared once again when the system rebooted!  It
  113.      turned out that these two programs had patched the boot-time OS
  114.      image (the kernel file, in UNIX terms) and had added themselves to
  115.      the list of programs that were to be started at boot time.
  116.  
  117.      The Robin Hood and Friar Tuck ghosts were finally eradicated when
  118.      the system staff rebooted the system from a clean boot-tape and
  119.      reinstalled the monitor.  Not long thereafter, Xerox released a
  120.      patch for this problem.
  121.  
  122.      It is alleged that Xerox filed a complaint with Motorola's management
  123.      about the merry-prankster actions of the two employees in question.
  124.      It is not recorded that any serious disciplinary action was taken
  125.      against either of them.
  126.  
  127. --- end ---
  128.