From: "Dave Emery" <die@pig.die.com>
Date: Wed, 28 Sep 94 13:56:47 PDT
To: dcwill@ee.unr.edu (Dr. D.C. Williams)
Subject: Re: Mandatory email verification
In-Reply-To: <199409281332.GAA11124@python>
Message-ID: <9409282054.AA01959@pig.die.com>
MIME-Version: 1.0
Content-Type: text/plain



> 
> All this system does is provide some reasonable protection for users against
> mail forgery originating from their own machine. My experiments with
> port 25 show that a telnet connection from a remote machine to port 25
> causes the remote machine's address to appear in the ESMTP headers. However,
> mail sent from a local connection to port 25 can't be readily distinguished
> from mail sent via "normal" mail programs (mail, elm, pine, etc.). On the
> systems I've examined, I can enter a user's login through port 25 and sendmail
> will affix his real identity from /etc/passwd just as though that user had
> sent the mail. For instance, a user can forge mail from root on their own
> machine. I don't know about you, but that's something that concerns me.
> It's entirely possible that someone impersonating root could send email to
> a user to change his password as a "system test", giving the bad guy access
> to someone else's account. Admittedly, this is a pretty benign example, but
> the potential for real damage is there.


	The last time I hacked a mailer (elm 2.4 to be specific) I
seem to remember that it invoced sendmail as a process rather than
connecting to it via port 25 to send mail. 

	It would seem that one could hack sendmail so as not to accept
non sendmail connections to port 25 from the local machine (it clearly
knows from the socket info structures who is connected on the other end
of the socket) or perhaps to refuse to accept user id from a port 25
connection on the local machine (instead indicating the origen of the
mail as user "sendmail25" or something similar).  The later approach
could be refined by adding a header line to the mail indicating it came
from port 25 rather than rejecting it - then all you would have to do is
make sure that the legitimate mailers were configured to invoke sendmail
as a process rather than via port 25, and the appearence of the warning
header line would be a red flag that something irregular happened in the
creation of the mail. 

	It might be necessary to hack the permanent sendmail process
listening on port 25 to accept mail from other spawned sendmail
processes via a memory to memory transfer (most unixes support this
these days) or via some other port than 25, or with an additional step
of passing the process id so it could check the UID of the process
sending it the mail to authenticate the sender.   [I am writing this
in a typically airheaded manner this afternoon without looking at
the sendmail source I have on the machine so I am a little vague about
how sendmail spawned talks to sendmail permanent to send mail, but whatever
technique is used here ought to be subject to a pass the process ID
or pass a magic cookie (hash of process ID and sendmail version perhaps?)
and the process id approach].

	Thus one need not bother with message signing at all, or if one wanted
to use it, could use it only to authenticate one sendmail process on your
local machine to another.