edwin@praxis.cs.ruu.nl (Edwin Kremer) (10/22/89)
Yesterday I discovered a nasty hole in the Elm security that would let anybody read no matter whose mailbox. This behaviour only occurs if you're running a Elm version that is SGID to e.g. group "mail". The following scenario took place at our site. For your information, our affected systems were: Harris HCX-9, HCX/UX 3.0, Elm 2.2 PL11 HP9000/370, HP-UX 6.5, Elm 2.2 PL11 HP9000/340, HP-UX 6.5, Elm 2.2 PL11 Imagine the following situation. The mail delivery agent is Sendmail that uses "/bin/mail" (from now on referenced as BINMAIL) for local delivery. The mail spool directory is '/usr/mail' and has permissions: drwxrwxr-x 2 bin mail 5120 Oct 21 19:51 /usr/mail User mailboxes have permissions like: -rw-rw---- 1 edwin mail 2813 Oct 21 17:31 /usr/mail/edwin -rw-rw---- 1 root mail 1069 Oct 19 13:34 /usr/mail/root BINMAIL has permissions: -r-xr-sr-x 2 bin mail 102400 Feb 17 1989 /bin/mail Elm has permissions: -rwxr-sr-x 1 root mail 266240 Oct 21 21:49 /local/bin/elm So far, so good. The mail spool directory '/usr/mail' must be writeble by group 'mail' in order to: 1) allow the local delivery mailer BINMAIL to create user mailboxes, 2) allow BINMAIL to create its lock files e.g. '/usr/mail/edwin.lock' The user mailboxes must be writable by group 'mail' as well in order to allow the local delivery mailer BINMAIL to write user mailboxes. The same story goes for Elm, it must read/write user mailboxes and it should use a BINMAIL like locking mechanism. Well, to achieve this, both BINMAIL and Elm are usually SGID to 'mail'. This also implies that both programs *may* be able to read all mailboxes, but the *real* permission checking mechanism in these programs usually prevents unwanted situations like these. Ok, now let's concentrate on Elm: it *really* checks if you've permission to read a mailbox, using the REAL GROUPID instead of the EFFECTIVE groupid (you may wish to check this by issuing a C)hange folder command to e.g. '/usr/mail/root' ==> Elm won't let you read it). Ok, now this is where we fail: Elm does not check permissions on the DEFAULT MAILBOX FILE at startup, this one is opened for reading anyway !!!!! Still no trouble uh, that file is '/usr/mail/my_login_name', right ?? Maybe, but Elm checks the environment variable MAIL first. Suppose I issue the following commands from my C-shell: % whoami edwin % setenv MAIL /usr/mail/root % elm ....... Wow, no access checking is done and I can read anyone's mailbox just by setting $MAIL to another value and invoking Elm after doing so... Well, I hope the Elm Development Group will comment on this. Meanwhile I suggest all system administrators to check out their Elm behaviour and apply the patch below if needed. Good luck. --[ Edwin ]-- #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *** init.c.ORIG Sat Oct 21 21:15:29 1989 --- init.c Sat Oct 21 21:18:29 1989 *************** *** 269,276 **** exit(0); } ! /* check for permissions only if not default mail file */ ! if(strcmp(requestedmfile, defaultfile) != 0) { if ((errno = can_access(requestedmfile, READ_ACCESS))) { dprint(1, (debugfile, "Error: given file %s as folder - unreadable (%s)!\n", --- 269,279 ---- exit(0); } ! /* ! * ALWAYS check for permissions on the mail file, even if ! * it's the default mailbox because users may fake another ! * default mailbox by setting their environment variable MAIL. ! */ if ((errno = can_access(requestedmfile, READ_ACCESS))) { dprint(1, (debugfile, "Error: given file %s as folder - unreadable (%s)!\n", *************** *** 280,286 **** Raw(OFF); exit(1); } - } /** check to see if the user has defined a LINES or COLUMNS value different to that in the termcap entry (for --- 283,288 ---- #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Edwin Kremer, Department of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Phone : +31 - 30 - 534104 | Telefax: +31 - 30 - 513791 E-Mail: edwin@cs.ruu.nl | UUCP to: ...!hp4nl!ruuinf!edwin
pete@tcom.stc.co.uk (Peter Kendell) (10/22/89)
From article <1726@ruuinf.cs.ruu.nl>, by edwin@praxis.cs.ruu.nl (Edwin Kremer): > Yesterday I discovered a nasty hole in the Elm security that would > let anybody read no matter whose mailbox. This behaviour only occurs > if you're running a Elm version that is SGID to e.g. group "mail". > Whoops! This also happens with DRS/NX (ICL version of SVR2) using smail and binmail. Time for patch 12, I suspect. -- ---------------------------------------------------------------------------- | Peter Kendell <pete@tcom.stc.co.uk> | | ...{uunet!}mcvax!ukc!stc!pete | ----------------------------------------------------------------------------
mjb@acd4.UUCP ( Mike Bryan ) (10/22/89)
In article <1726@ruuinf.cs.ruu.nl> edwin@praxis.cs.ruu.nl (Edwin Kremer) writes: >Yesterday I discovered a nasty hole in the Elm security that would >let anybody read no matter whose mailbox. This behaviour only occurs >if you're running a Elm version that is SGID to e.g. group "mail". > >User mailboxes have permissions like: > > -rw-rw---- 1 edwin mail 2813 Oct 21 17:31 /usr/mail/edwin > -rw-rw---- 1 root mail 1069 Oct 19 13:34 /usr/mail/root > >BINMAIL has permissions: > > -r-xr-sr-x 2 bin mail 102400 Feb 17 1989 /bin/mail > >The user mailboxes must be writable by group 'mail' as well in order to >allow the local delivery mailer BINMAIL to write user mailboxes. >The same story goes for Elm, it must read/write user mailboxes and it >should use a BINMAIL like locking mechanism. > We do not have the problem here. Our user mailboxes are setup with permission "-rw-------", and /bin/mail is setup as setuid root, not setgid mail. We are running Ultrix 3.1 and Ultrix 2.3; these are the default permissions as supplied by DEC. You neglected to say what flavor of UNIX you are using. I still think Elm should be corrected, since your setup sounds like a valid way to handle mail security. I found another problem in Elm while checking out yours, however. If a mail folder is specified which you cannot access (such as another user's), Elm will not exit. It comes up saying the mailbox has 0 entries (even though it has several). Typing "Q" or "q" results in Elm saying that the quit has been cancelled, since new mail has just arrived. It then tries to re-read the file (again, finding nothing), and the whole process starts over. I was able to quit with a SIGQUIT. Maybe Elm needs a Meta-Quit? (Or maybe it does, and I just don't know it...) BTW, I'm running ELM PL10. -- Mike Bryan, Applied Computing Devices, 100 N Campus Dr, Terre Haute IN 47802 Phone: 812/232-6051 FAX: 812/231-5280 Home: 812/232-0815 UUCP: uunet!acd4!mjb INTERNET: mjb%acd4@uunet.uu.net "Agony is born of desire; that's what you get for wanting." --- Moev
edwin@praxis.cs.ruu.nl (Edwin Kremer) (10/23/89)
In article <1989Oct22.155409.3857@acd4.UUCP> mjb@acd4.UUCP (Mike Bryan) writes: > We do not have the problem here. Our user mailboxes are setup with > permission "-rw-------", and /bin/mail is setup as setuid root, not > setgid mail. We are running Ultrix 3.1 and Ultrix 2.3; these are the > default permissions as supplied by DEC. Ah, but haven't we seen security flaws introduced by programs that were SUID to root and allowed shell escapes ?? One step forward to UNIX security is that you don't have programs SUID to root *unless* it's really necessary. I mean, if SGID can handle it, why use SUID ???? If there's a leak in a program, then the highest rank an intruder can become is that of group mail instead of user root. That's why I prefer SGID. > You neglected to say what flavor of UNIX you are using. Well, I mentioned HCX-UX 3.0 and HP-UX 6.5. Both are merely treatened as System V systems, with the BSD goodies thrown in. > I found another problem in Elm while checking out yours, however. If > a mail folder is specified which you cannot access (such as another > user's), Elm will not exit. It comes up saying the mailbox has 0 > entries (even though it has several). Right. I noticed that as well. This is because Elm doesn't do access check, sets up the screen, then notices that opening the mailbox fails. This is what happened when I dropped the SGID bit from Elm. Anyway, if you apply my patch, this strange behaviour will go away as well. --[ Edwin ]-- -- Edwin Kremer, Department of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Phone : +31 - 30 - 534104 | Telefax: +31 - 30 - 513791 E-Mail: edwin@cs.ruu.nl | UUCP to: ...!hp4nl!ruuinf!edwin
elliot@alfred.UUCP (Elliot Dierksen) (10/23/89)
In article <126@sneezy.tcom.stc.co.uk>, pete@tcom.stc.co.uk (Peter Kendell) writes: > From article <1726@ruuinf.cs.ruu.nl>, by edwin@praxis.cs.ruu.nl (Edwin Kremer): > > Yesterday I discovered a nasty hole in the Elm security that would > > let anybody read no matter whose mailbox. This behaviour only occurs > > if you're running a Elm version that is SGID to e.g. group "mail". > > Well, I hate to be a pain but you can also AT&T 3B2 & 7300 to the list of systems that exhibit this problem.... I must say, I think elm is an excellent product, but I hope to see a patch VERY soon to resolve this!!!! -- Elliot Dierksen Home: {peora,ucf-cs,uunet}!tarpit!alfred!elliot Work: {att,codas}!candi!ralph!ebd "My Cow died, so I don't need your Bull any more!"
syd@DSI.COM (Syd Weinstein) (10/23/89)
edwin@praxis.cs.ruu.nl (Edwin Kremer) writes: >Yesterday I discovered a nasty hole in the Elm security that would >let anybody read no matter whose mailbox. This behaviour only occurs >if you're running a Elm version that is SGID to e.g. group "mail". [...] >Well, I hope the Elm Development Group will comment on this. Meanwhile >I suggest all system administrators to check out their Elm behaviour >and apply the patch below if needed. Good luck. Before I even saw this news article, my mailbox had a message from one of my local sites stating that the supplied patch will not work. It actually works too well. it causes you to get the message even in send only mode. (ie elm user@host). Patch 12 is already cut and awaiting testing feedback before being posted. This security hole will be fixed in patch 13. Our official patch will, hopefully, work for send only mode and the default mailbox. We will also attempt to see if any of the utilities have similar problems. Due to the nature of this hole, and the fact that Edwin reported it to the net first, before we could get a fix ready, we will expidite the patch. Please, for security problems, please let the vendor or author know first so a work around or patch can be derived, before making it public. If, indeed, the vendor or author is uncooperative, then by all means embarrass them, however, in this case, this is the first we heard of this problem. Now for what sites are effected: USG type sites are effected. BSD type are not. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
edwin@praxis.cs.ruu.nl (Edwin Kremer) (10/23/89)
In article <1989Oct22.222227.27140@DSI.COM> syd@DSI.COM (Syd Weinstein) writes: > Before I even saw this news article, my mailbox had a message from one > of my local sites stating that the supplied patch will not work. > It actually works too well. it causes you to get the message even in > send only mode. (ie elm user@host). Oops, you're right. Syd means that if you fake another ones mailbox by saying: setenv MAIL /usr/mail/root, then issue: elm user@site you'll get a message like 'Can't open folder /usr/mail/root' and Elm will exit immediately. Ok, this is maybe not what we want, but it sure stops bad guys faking other ones mailboxes. > Please, for security problems, please let the vendor or author know > first so a work around or patch can be derived, before making it public. Maybe you're right, but a found this one so urgent that I decided to post it. Do you know how many mail boxes have already been read by some bad guys who knew about this problem ??? More worse, if I mailed it to you first, (and you're system was affexted) anyone with access to your machine might have read it AND thrown it away !! (without you noticing my urgent mail message ever) You know, this was a situation in which you ask yourself "Can I trust mailing this or should I post it as soon as possible ??" Besides, I made sure to send out a patch as well. Ok, maybe my patch wasn't the best one ever published but it surely solves the problem. My apoligies to all of you who hate my posting and like to blow my head of as soon as possible for posting this. --[ Edwin ]-- -- Edwin Kremer, Department of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Phone : +31 - 30 - 534104 | Telefax: +31 - 30 - 513791 E-Mail: edwin@cs.ruu.nl | UUCP to: ...!hp4nl!ruuinf!edwin