[comp.mail.sendmail] Security in sendmail and SMTP?

dejong@idca.tds.PHILIPS.nl (Hans de Jong) (06/03/91)

I am trying to find out about security in sendmail and SMTP. What I see is:

1) Sendmail has no possibility to change headers in a mail item. It can add
   header lines, but will not affect them when they are present.
2) The only exception seems to be the From: line, but only the machine name
   part of the address. Changing that requires root permission. 
   But the user can directly set the username as well as the full name.
3) SMTP uses no passwords. So any machine that can connect to another machine
   will be accepted as the machine it pretends to be (i.e., whatever is in
   the HELO command or MAIL FROM: command is accepted.

My questions are:

1) Are my observations correct?
2) Are there options in sendmail to avoid that the user can pretend to send
   mail as someone else?
3) Reading RFC821, the From: line may be set to indicate another user than the
   one actually sending. In that case there should be a Sender: line present
   to indicate who the actual sender is. But sendmail doesn't seem to enforce
   this. At the same time, it doesn't allow for a different machine name in
   From: than the own machine (unless I am superuser). 
   Is there literature outside RFC821 that describes how the From:, Sender:,
   Resent-From: and Resent-Sender: lines have to be treated.

Thanks

Hans

karl.kleinpaste@osc.edu (06/03/91)

dejong@idca.tds.philips.nl writes:
   1) Sendmail has no possibility to change headers in a mail item. It can add
      header lines, but will not affect them when they are present.
   2) The only exception seems to be the From: line, but only the machine name
      part of the address. Changing that requires root permission. 
      But the user can directly set the username as well as the full name.

When suitably (mis-)configured, sendmail can hack on nearly any header
present.  It will definitely hack on Sender:, From:, To:, Cc:, and (I
believe) Reply-To:.  Your particular installation may leave more
things alone that someone else's.  This has to do with how much there
is to your rulesets such as S1 and S2 in particular, and whether S3 is
particularly relevant to how your installation canonicalizes.  For
myself, S3 is nearly the entire universe of hacking, and S[12] are
empty.

   3) SMTP uses no passwords. So any machine that can connect to another
      machine will be accepted as the machine it pretends to be (i.e.,
      whatever is in the HELO command or MAIL FROM: command is accepted.

It will be accepted, yes; but the Received: header will normally
reflect what sendmail believed to be the case regarding the host to
which it was speaking at the time; for example:

Received: from bogus.name.org (real.entity.edu) by my.host.com

What you see there is that the originating SMTP speaker identified
itself during HELO as bogus.name.org.  Regardless of the speaker's
claims, sendmail knows the IP addr of the origin, and it calls
gethostbyaddr() to learn that it was really real.entity.edu which was
connected at the time.

   1) Are my observations correct?

Partly.

   2) Are there options in sendmail to avoid that the user can pretend to send
      mail as someone else?

There is no fundamental way to prevent the sending of mail as someone
other than oneself; anyone can "telnet desti.nation.edu smtp" and
find themselves speaking to the right program, and can speak the SMTP
dialogue as well as an SMTP-speaking program.  If you're careful, you
can do a very complete forgery.

See RFCs 1113, 1114, and 1115 for details on privacy-enhanced mail.  I
am not aware of much yet in the way of implementations of these, but
progress is being made -- I think there's an IETF group working on the
problem.

   3) Reading RFC821, the From: line may be set to indicate another
      user than the one actually sending. In that case there should be
      a Sender: line present to indicate who the actual sender is. But
      sendmail doesn't seem to enforce this.

In that case, your sendmail is broken somehow.  The only way that
sendmail should allow a modified From: field to pass is if the sending
user is one of the "trusted users" (T entry in sendmail.cf).
Otherwise, a Sender: identifying the real user is added -- mine does it.

      At the same time, it
      doesn't allow for a different machine name in From: than the own
      machine (unless I am superuser).

That's a question of the configuration.  You can do many, varied, and
weird things to what sorts of origin hostnames you identify in From:
via suitable hacks to sendmail.cf, and I don't know why any of it
would necessarily be affected by superuser status (except as a trusted
user again, but I don't think this falls into those categories).  A
common thing for a configuration to do is to hide individual hostnames
for a set of hosts within a single (sub)domain, if the user is
reachable at the host which is the "domain head."  In such a case, the
Received: and Message-Id: headers may contain notations of individual
hosts, but things like From: and Reply-To: will generally contain only
a top-level domain name.

      Is there literature outside RFC821 that describes how the From:, Sender:,
      Resent-From: and Resent-Sender: lines have to be treated.

See RFC1123, in part.

--karl

rickert@mp.cs.niu.edu (Neil Rickert) (06/03/91)

In article <1443@idcapd.idca.tds.philips.nl> dejong@idca.tds.PHILIPS.nl (Hans de Jong) writes:
>I am trying to find out about security in sendmail and SMTP. What I see is:
>
>1) Sendmail has no possibility to change headers in a mail item. It can add
>   header lines, but will not affect them when they are present.

 If you use a vanilla sendmail compiled from Berkeley sources, the following
headers will be rewritten:
  To:
  Cc:
  Apparently-To:
  From:
  Reply-To:
  Return-Receipt-To:
  Errors-To:
  Sender:
  Bcc:
  Resent-To:
  Resent-Cc:
  Resent-From:
  Resent-Reply-To:
  Resent-Sender:
  Resent-Bcc:

 With a standard configuration file, if the addresses are all standard
Internet addresses, and the destination is an Internet destination, these
addresses should all be rewritten to the same value as they originally
had, except the Bcc: and Resent-Bcc: headers will be deleted.  But it is
possible for almost any transformation, reasonable or not, to be programmed
into 'sendmail.cf'.  Not merely the machine address, but anything can be
changed.


>2) The only exception seems to be the From: line, but only the machine name
>   part of the address. Changing that requires root permission. 
>   But the user can directly set the username as well as the full name.

 I am not sure what you mean by this.  Root, or some similar permission is
"required" to specify the '-f' option on the command line.  But this has
nothing whatsoever to do with changing the headers.  If the message
entering sendmail already has a 'From:' header, the '-f' option is unlikey
to change that.  Anybody can construct a message with whatever headers they
wish and pipe it into sendmail.  There is no restriction on that.  The '-f'
option has to do with the SMTP envelope sender address, not with the
'From:' header.  Of course, if there is no 'From:' header in the entering
mail, and if the 'sendmail.cf' specifications define one, they will usually
define it in terms of the envelope sender.

 Note my quoting of "required" in the preceding paragraph.  There are
definitely ways around this restriction.

>3) SMTP uses no passwords. So any machine that can connect to another machine
>   will be accepted as the machine it pretends to be (i.e., whatever is in
>   the HELO command or MAIL FROM: command is accepted.

  Correct.  And I believe this is the proper behavior.  A properly configured
sendmail adds a 'Received:' header identifying the machine from which it
received the message.  It is reasonably for 'sendmail' to in effect say that
sender authentication is the province of the sending machine, so the address
should be accepted with a 'Received:' header added to identify the originating
host.

>My questions are:
>
>1) Are my observations correct?
>2) Are there options in sendmail to avoid that the user can pretend to send
>   mail as someone else?

 There are options which allow you to invoke sendmail with your own
'sendmail.cf' configuration.  I don't recommend trying them because it is quite
easy to screw up.  But if you are willing to deal with the fact that sendmail
will then run without its usual root privileges, you more or less have carte
blanche.

>3) Reading RFC821, the From: line may be set to indicate another user than the
>   one actually sending. In that case there should be a Sender: line present
>   to indicate who the actual sender is. But sendmail doesn't seem to enforce
>   this. At the same time, it doesn't allow for a different machine name in
>   From: than the own machine (unless I am superuser). 

  As I indicated above, 'sendmail' will accept at face value whatever is on
the 'From:' line of incoming mail, regardless of whether you are root.  It is
only the SMTP envelope address it is fussy about.

>   Is there literature outside RFC821 that describes how the From:, Sender:,
>   Resent-From: and Resent-Sender: lines have to be treated.

  Try RFC822.


-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940