Article View: comp.mail.misc
Article #1804Re: Shell scripts from smail/sendmail - strange behavior
From: Jonathan I. Kamens
Date: Sun, 14 Oct 1990 22:46
Date: Sun, 14 Oct 1990 22:46
47 lines
3230 bytes
3230 bytes
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
Technical Details
Message-ID:
<1990Oct14.224615.6178@athena.mit.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!athena.mit.edu!jikReferences:
<1990Oct10.200803.27014@supernet.haus.com> <1990Oct14.135213.28213@athena.mit.edu> <1990Oct14.194452.13627@mp.cs.niu.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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