reeder@ut-emx.UUCP (William P. Reeder) (02/28/89)
After I installed sendmail 5.61 (replacing 5.54) I got complaints from users about forwarding being broken. Here is what happens under 5.61: o User fred sets up ~fred/.forward to forward mail to |/home/fred/fredscript. o User cathy sends fred some mail. o sendmail 5.61 runs the program specified in ~fred/.forward under cathy's uid and gid (from /etc/passwd). This may fail, depending on protections set on fred's directories and files. o User "james@some.other.host.edu" sends fred some mail. o sendmail 5.61 runs the same program, but under uid 1 and gid 1 (as per directions in /usr/lib/sendmail.cf). This may fail, depending on protections set on fred's directories and files. Now imagine each of the following scenarios: #1 o User calvin sets up ~calvin/.forward to run his research program. o User calvin sends mail another local user asking a question. o Local user responds to calvin's question, and calvin's program is run under other user's uid and gid. This succeeds because calvin has been very careful with his protections. calvin gets lots of work done, all for free. Meanwhile, people can't figure out how come they keep running out of money. #2 o User schnook sets up ~schnook/.forward to do dirty deeds. o User schnook sends mail to local guru, asking a question. o Local guru reads mail and replies. o User schnooks program is run, doing its dirty deeds under guru's uid and gid. This works because lots of interesting files are in one of the many interesting groups to which guru belongs, and because these interesting files are group writable or readable. It also turns out that these dirty deeds are run dirt cheap (from schnook's point of view) because accounting is to guru's uid. This seems like a fairly serious security hole. Do others care to comment on the question: Why would you want to run a program under the user id of the sender, rather than under the uid of the recipient who asked for the program to be run? My users' complaints about forwarding imply that sendmail 5.54 would run programs under the uid of the owner of the .forward file. (There is a check in 5.61 to make sure the .forward file is owned by the recipient.) Routine setsender() in src/envelope.c is the one which checks to see if the sender is local, and resets DefUid and DefGid if (s)he is. This code is essentially unchanged from 5.54 to 5.61. I am still tracking the code which does forwarding to try to find what has changed here, and perhaps why. William Reeder postmaster@emx.utexas.edu, reeder@emx.utexas.edu -- DISCLAIMER: I speak only for myself, and usually only to myself.
reeder@ut-emx.UUCP (William P. Reeder) (03/01/89)
More info on my problem with sendmail 5.61: - I am running on an Encore Multimax, not a VAX. - We use the "queue only" mode (Odq) for load limiting reasons. The second point above seems to be the critical one. If sendmail is allowed to do delivery when called by the user's mail program, then the following happens: - the local recipient's name becomes the "controlling address", ctladdr, and the QGOODUID flag is set. - forwarding is done under the auspices of the controlling address. Specifically, forwarding to a program gets the program run under the uid and gid of the controlling address. This is good. If, however, sendmail is directed to only queue messages, then this is what happens: - when sendmail is invoked by the user's mail program it performs aliasing and forwarding on the various addresses and produces a queue file and a data file. If the recipient is local and has forwarded to a program, then the queue file (qf*) contains a line of the form "R|/path/prog". Sendmail exits. - during the next queue run, sendmail finds a recipient which is a program. Note that the information about whose .forward file requested the forwarding is lost. Since the recipient (a program) has no password file entry, the QGOODUID flag cannot be set and sendmail must run the program under the defualt uid and gid (DefUid and DefGid). BUT, back in readqf() sendmail had called setsender() with the S entry in the queue file. If the S entry specifies a local user, then DefUid is set to the uid of the sender, and DefGid is set to the gid of the sender. I believe this to be a security hole. As a system programmer, I am in several "interesting" groups. And there are several "interesting" files which are "interesting" group write-able or read-able. If I locally send mail (as opposed to sending mail from my workstation) to a local user, then I am compromising the security of my system. Unfortunately, our Encore behaves so badly under certain load conditions that we are extremely reluctant to run with "Odb". When I say badly, I don't just mean that things get slow, I mean that the machine may have to be powered off to restore functionality. My statement of our reluctance is perhaps the understatement of the (new) year. I would like your opinions. Is sendmail's running a program under the uid of the sender a bug? A security hole? Should I report it as a bug to Berkeley? Is anyone responsible from Berkeley reading this newsfroup? By the way, I believe that sendmail 5.54 works the same way in this regard. At the same time I installed 5.61, I switched from asynchronous delivery to queueing in an attempt to be a good citizen on our machine. William Reeder reeder@emx.utexas.edu, postmaster@emx.utexas.edu -- DISCLAIMER: I speak only for myself, and usually only to myself.