Xref: utzoo comp.mail.misc:4135 comp.unix.shell:577
Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.mail.misc,comp.unix.shell
Subject: Re: Shell scripts from smail/sendmail - strange behavior
Message-ID: <1990Oct14.224615.6178@athena.mit.edu>
Date: 14 Oct 90 22:46:15 GMT
References: <1990Oct10.200803.27014@supernet.haus.com> <1990Oct14.135213.28213@athena.mit.edu> <1990Oct14.194452.13627@mp.cs.niu.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: jik@athena.mit.edu (Jonathan I. Kamens)
Organization: Massachusetts Institute of Technology
Lines: 47

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