Nasty Security Hole?

[Brandon S. Allbery]

As quoted from <1988Nov13.192003.22144 at gpu.utcs.toronto.edu> by woods at gpu.utcs.toronto.edu (Greg Woods):
+---------------
| In article <850 at sceard.UUCP> mrm at sceard.UUCP (0040-M.R.Murphy) writes:
| >Note the ownerships, stickies, and permissions.
| >drwxrwxr-x   2 root     mail         256 Nov 10 10:21 /usr/mail
| >-rwxr-sr-x   1 bin      mail       25066 Oct 26  1985 /bin/lmail
| >-rwxr-sr-x   1 bin      mail       15000 Feb 17  1988 /bin/mail
| >-rwxr-sr-x   2 bin      mail       42292 Feb 17  1988 /bin/rmail
| >-rwxr-sr-x   2 bin      mail       42292 Feb 17  1988 /bin/smail
| >-rwxr-sr-x   1 bin      mail       99306 Oct 27  1985 /usr/bin/mailx
| >Happens to be smail2.5, but the principles are the same with other
| >mailers.
| 
| I doubt you need set-group-id on mailx, since it only manipulates the
| user's own mailbox.  Making it set-gid will allow anyone to read or
| write all system mailboxes.  I've also found that no implementation of
| mailx or BSD Mail (that I've used) bothers to reset real uid and gid
| when spawning a sub-process, at least not when sending mail.
+---------------

Don't try this at home, kids.

If you're unlucky enough to have a mailer which uses links to lock mailboxes,
mailx MUST be set[ug]id (which depends on whether you run your primary
mailer [/bin/mail] setuid or setgid).  As far as I know, all System V's
still use links because someone was afraid that record locks can't emulate
file locks.  (hmph; just lock the byte AFTER eof!)

++Brandon
-- 
Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X
uunet!hal.cwru.edu!ncoast!allbery  <PREFERRED!>	    ncoast!allbery at hal.cwru.edu
allberyb at skybridge.sdi.cwru.edu	      <ALSO>		   allbery at uunet.uu.net
comp.sources.misc is moving off ncoast -- please do NOT send submissions direct
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>.