cluther@supernet.haus.com (Clay Luther) (10/11/90)
I posted something earlier about a script running from a smail/sendmail alias (as root) being unable to move files into unwritable directories. This is a follow-up post. Well, it turns out that we have some wierd behavior going on here, possibly with smail. I don't know and everyone here is scratching their heads. OK... I have a script that expects to receive formatted files from stdin. This script is owned by root. The script is attached to a smail/sendmail alias like so: foo:"|/usr/spool/foo/foo.sh" so that when mail receives mail for foo@bar, the program foo.sh is invoked with the mail data as input. OK fine. Here's the weird part. The foo.sh program is being invoked *not* as root, but as cluther, my user account!!! Aha! I said, I forgot to make foo.sh owned by root. Uh, nope, foo.sh is owned by root. Aha! I said, smail must be running as cluther! Wild quess region here. Smail is and always has been a root id program. I even went so far to check all the smail config and source files for cluther. Nothing. Aha! I said, maybe there is some "strange" interaction between smail and the aliases file. Since cluther appears generously throughout it, maybe, just maybe...Again, this is voodooville, but hey, at I get points for initiative. Nope, it was not the alias file/smail interaction, as far as I could tell. Some facts: Yes, I did write the shell program as cluther, but it current owner and current group is root. No, I don't think I ever compiled smail as cluther, or the alias files as cluther. Although, if this is relevant, I received my original sources in my cluther account. Smail was compiled by root. We are running CTIX/386, SysVr3 Other strangeness: I create a new script, newfoo.sh, by vi'ing newfoo.sh as root, reading in the old script, and saving the file *as root*. Then chmod +x and switched the foo alias to point to newfoo.sh instead of foo.sh. Guess what...newfoo.sh was invoke as a cluther id program when smail invoked the foo alias. Wonder years. Well, that's all I can think of. Hopefully somebody can provide some answers. -- Clay Luther, Postmaster cluther@supernet.haus.com postmaster@supernet.haus.com clay.luther@supernet.haus.com Harris Adacom Corporation MS 23, PO Box 809022, Dallas, Tx 75380-9022 214/386-2356 Your mileage may vary. Void where prohibited.
jik@athena.mit.edu (Jonathan I. Kamens) (10/14/90)
Sendmail (I don't know about smail, but I suspect, given the description of
your problem, that it's similarly brain-damaged) has a "feature" that is
probably causing your difficulties.
When sendmail needs to run a program out of the aliases file, the user ID
under which the program will run DEPENDS ON THE RETURN ADDRESS OF THE MAIL.
Really.
If the originating address is on the same machine as the sendmail that's
running the script, then the script is run as the user identified in the
originating address. If, however, the originating address indicates a sender
not on the same machine as the sendmail, then the script is run as root, or
daemon, or whatever sendmail decides to run it as (I think it's configurable;
at my site, it runs as daemon).
I installed the following test script as an alias on my system, and then
sent mail to myself containing "From: " lines with "jik" in them and
"jik@athena.mit.edu" in them. In the former case, the data returned from the
script indicated that it was running as jik; in the latter, the script ran as
daemon:
#!/bin/sh
ME=`/usr/ucb/whoami`
ME2=`/bin/who am i`
(echo "/usr/ucb/whoami returns $ME";
echo "/bin/who am i returns $ME2";
echo "Message follows:";
echo "";
cat) | mail jik
EOF
exit 0
The solution to the problem? Write your script as a C program (or write a
stub C program that actually executes the script), and make it setuid to
daemon, or to root, or to whomever else you wish it to run as. And get
Berkeley to change this behavior of sendmail, which has been around forever
(ane which has been wrong for nearly forever :-). Actually, that last part
may not be relevant -- I'm testing with version 5.61, and version 5.64 may
have fixed this problem.
--
Jonathan Kamens USnail:
MIT Project Athena 11 Ashford Terrace
jik@Athena.MIT.EDU Allston, MA 02134
Office: 617-253-8495 Home: 617-782-0710rickert@mp.cs.niu.edu (Neil Rickert) (10/15/90)
In article <1990Oct14.135213.28213@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > And get >Berkeley to change this behavior of sendmail, which has been around forever >(ane which has been wrong for nearly forever :-). Actually, that last part >may not be relevant -- I'm testing with version 5.61, and version 5.64 may >have fixed this problem. > It is not so clear to some of us that sendmail's behavior is wrong. Infuriating - yes. Wrong - I don't think so. The ideal would be for sendmail to read my mind, and follow its current behavior when I want that, and Kamen's preferred behavior at other times. Basically it is trying to allow permissions to control who can send email to a programatic mailer (such as the msgs command which posts notices). You can always get Kamen's preferred behavior by means of suid programs. But if his preference were the default it would be difficult to get the other behavior without doing extensive sender checking in program mail handlers. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
jik@athena.mit.edu (Jonathan I. Kamens) (10/15/90)
In article <1990Oct14.194452.13627@mp.cs.niu.edu>, rickert@mp.cs.niu.edu (Neil Rickert) writes: |> In article <1990Oct14.135213.28213@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: |> > And get |> >Berkeley to change this behavior of sendmail, which has been around forever |> >(ane which has been wrong for nearly forever :-). Actually, that last part |> >may not be relevant -- I'm testing with version 5.61, and version 5.64 may |> >have fixed this problem. |> > |> It is not so clear to some of us that sendmail's behavior is wrong. |> Infuriating - yes. Wrong - I don't think so. |> |> The ideal would be for sendmail to read my mind, and follow its current |> behavior when I want that, and Kamen's preferred behavior at other times. |> |> Basically it is trying to allow permissions to control who can send email |> to a programatic mailer (such as the msgs command which posts notices). You |> can always get Kamen's preferred behavior by means of suid programs. But if |> his preference were the default it would be difficult to get the other |> behavior without doing extensive sender checking in program mail handlers. First of all, my name is Kamens, not Kamen. But that's not important right now :-). Second, I didn't see the point in mentioning this before, but if you're going to start debating, I might as well -- the behavior I have described is a GAPING and KNOWN security hole in sendmail. I can, on many (if not most) systems, pretty much run any program as any user if I have an account on the system and its sendmail behaves as I've described. "Extensive sender checking" is EXACTLY what sendmail 5.61 DOES NOT do when it decides what user ID to use when running a program. And, as any somewhat knowledgeable Unix user should know, it's REAL easy to fake sendmail out. That's why this functionality was removed in sendmail 5.64. As I've said once already, if your vendor's version of sendmail has this functionality, then flame at your vendor to fix it, and in the mean time, get the sources to a newer version of sendmail and install it. I'm not going to go into more detail about the security problems, because if you can't figure it out from what I've written, then you probably don't need to know about it. (1/2 :-) -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/15/90)
In article <1990Oct14.224615.6178@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > "Extensive sender checking" is EXACTLY what sendmail 5.61 DOES NOT do when > it decides what user ID to use when running a program. And, as any somewhat > knowledgeable Unix user should know, it's REAL easy to fake sendmail out. Yep, I always thought -bs was an appropriate option name. :-) To dive off into this side thread: If you want to accurately log mail coming into your (BSD) system, look at the sendmail-auth directory in my authutil package (c.s.unix volume 22). Assuming you already have authtcp and attachport installed, you have to install just a couple of ten-line shell scripts and make a few changes to sendmail.cf and rc.local. Then connections will be logged in /usr/adm/in.mail.log as, e.g., Date: Mon Apr 23 22:58:27 CST 1990 972 from root@128.122.128.22 via TCP Done: Mon Apr 23 22:58:38 CST 1990 972 984 if the remote site supports RFC 931. As more and more hosts realize the advantages of authentication, the unauthenticated connections will begin to stand out as forgeries, so you can simply chop them off. In the meantime, we can hope that Berkeley will fix the talk-to-myself bug, eliminate -bs, fix the uid bugs, and build in RFC 931 support... A longer-term advantage of this strategy is that you won't have to recompile anything to run mail over a more secure communications system, such as Kerberos. If Jon codes Kerberized authtcp/attachport, that is... ---Dan
rickert@mp.cs.niu.edu (Neil Rickert) (10/15/90)
In article <1990Oct14.224615.6178@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > First of all, my name is Kamens, not Kamen. But that's not important right >now :-). > My apologies for the typo on your name. > Second, I didn't see the point in mentioning this before, but if you're >going to start debating, I might as well -- the behavior I have described is a >GAPING and KNOWN security hole in sendmail. I can, on many (if not most) >systems, pretty much run any program as any user if I have an account on the >system and its sendmail behaves as I've described. > I thought we were discussing programs invoked due to an entry in the aliases file. I fully agree that having a publicly writeable aliases file is a security hazard. > "Extensive sender checking" is EXACTLY what sendmail 5.61 DOES NOT do when >it decides what user ID to use when running a program. And, as any somewhat >knowledgeable Unix user should know, it's REAL easy to fake sendmail out. This is why you should be careful about putting programs in aliases. >That's why this functionality was removed in sendmail 5.64. That is indeed curious. I am using a sendmail 5.64 derivative, and when I post a 'msgs', it still runs the program under my user ID. My mail is submitted by an SMTP client, so that sendmail itself is running with real uid of root at the time. Certainly there were changes made to handling of 'uid's, but I haven't seen any evidence that "this functionality was removed in 5.64." -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940