There are a number of security holes that can be opened up by commands
given carelessly in the configuration file. Such holes can be
serious because
sendmail
starts to run as
root
,
provided that it has not been given an unsafe command-line switch
(such as
-C
; see
Section 36.7.15, -C
) or an unsafe option
(see
Section 34.1.4, "Options that Are Safe"
).
It continues as
root
until it delivers mail, whereupon
it changes its identity to that of an ordinary user. When
sendmail
reads its configuration file, it generally does so
while it is still
root
. Consequently, as we will illustrate,
it may be able to read and overwrite any file.

This package is used to screen incoming network connections and
to accept or reject them on the basis of hostname, domain, or IP
number. It is a powerful adjunct to security, and if you have
not already done so, you should install it at your site.

Prior to V8.8 the only way
sendmail
could take advantage
of this package was to be run from
inetd
(8) (see
Section 36.7.11, -bs
).
Beginning with V8.8
sendmail
, support for this package
is built in.

If TCPWRAPPERS is defined in compiling (see
Section 18.8.49, TCPWRAPPERS
),
sendmail
will automatically use that package to verify and
screen all incoming SMTP connections. If, as CERT
recommends, you have ALL:ALL in your
hosts.deny
file,
you will need to add this line to your
hosts.allow
file:

sendmail:ALL

Then, to selectively reject connection, you might add a line like
this to your
hosts.deny
file:

sendmail:spam.host.domain

This causes the TCP wrapper package to tell
sendmail
to reject all SMTP connections from the spamming host
spam.host.domain
.

When mail comes in from
spam.host.domain
,
sendmail
will issue this SMTP message as a reply to all
SMTP commands from that host:

550 Access denied

The only exception is the QUIT command (and beginning with
V8.8.5, the HELO, EHLO, and NOOP commands), which
allows the spamming host to disconnect.

Use of the TCP wrapper package imposes additional network
traffic that may not be desirable. Both it and
sendmail
, for
instance, may look up the same host with DNS. The wrapper
software also sends
identd
(8) queries that a duplicate
those used by
sendmail
. Finally, note that two files
need to be opened and read for each connection. We recommend that
you exclude support for this package (especially at high-volume
sites) until you actually need it. At low- to medium-volume
sites you may wish to include support for this package in
sendmail
but
then to not implement that support (in
hosts.allow
and
hosts.deny
) until the need arises.

This form is used to read class macro entries from files.
It can cause problems through a misunderstanding of the
scanf
(3) pattern
pat
.
The
/path
is the name of the file,
and the optional
pat
is a pattern to be used by
scanf
(3)
(see
Section 32.1.2.1, "scanf(3) variations"
).

To illustrate the risk of the
pat
, consider
the following configuration file entry:

Fw/etc/myhostnames %[^#]

Normally, the
F
command reads only the first whitespace-delimited
word from each line of the file. But if the optional pattern
pat
is specified, the
F
command instead reads
one or more words from each line based on the nature of the pattern.
The pattern is used by
scanf
(3) to extract words, and the
specific pattern used here
[^#]
causes
scanf
(3) to
read everything
up to the first comment character (the
#
) from each line.
This
pat
allows multiple hostnames to be conveniently
listed on each line of the file.
Now assume that a new administrator,
who is not very familiar with
sendmail
,
decides to add an
F
command to gather a list of UUCP hosts from
the
/etc/uucp/Systems
file. Being a novice, the new administrator
copies the existing entry for use with the new file:

FU/etc/uucp/Systems %[^#]

This is the same pattern that was correctly used for
/etc/myhostnames
.
Unfortunately, the
Systems
file contains more than just host
entries on each line:

A part of each line (the last item in each) contains nonencrypted passwords.
An unscrupulous user, noticing the mistaken
[^#]
in the
configuration file, could run
sendmail
with a
-d36.5
debugging switch and watch each password being processed. For example,

Note the third line from the bottom, where the password for the UUCP
login into the host
hoby
is printed.
This example illustrates two rules about handling the configuration file:

Avoid using the
F
command to read a file that is not already
publicly readable. To do so can reveal sensitive information.
Even if the
scanf
(3) option is correct, a core dump
[10]
can be examined for sensitive information from otherwise secured files.

[10] Most versions of UNIX disallow core dumps of
suid
root
programs.

Avoid adding a new command to the configuration file by blindly copying
and modifying another. Try to learn the rules governing the command
first.

Another form of the
F
(File) configuration command is the program
form, which looks like this:

F
X|/path

Here, the
|
prefix to the
/path
tells
sendmail
that
/path
is the name of a program to run. The output produced
by the program is appended to the class, here
X
.

To illustrate another potential security risk,
consider a configuration file that is group writable, perhaps
by a few administrators who share the job of
postmaster
.
To break into
root
, the attacker only needs to assume the identity
of one of those users and, under that identity, edit the configuration file.
Consider the following bogus entry added by an attacker to that configuration file:

With these changes in place, the program (actually a shell script) called
/tmp/.sh
is run by
sendmail
to fill the class
X
with new values.
All this seems harmless enough, but suppose
/tmp/.sh
does the unexpected:

#!/bin/sh
cp /bin/sh /tmp/.shell
chmod u+s /tmp/.shell

Here, the Bourne shell is copied to
/tmp/.shell
, and the
suid
root
bit is set. Now, any user at all can run
sendmail
and
become
root
:

The
sendmail
configuration file must
never
be writable by anyone
other than
root
. It should also live in a directory,
every path component of which is owned by and writable only by
root
.
(We'll discuss this latter point in greater detail soon.)
If the configuration file is created with the
m4
technique, then
care must be taken to ensure that only
root
can install it.

Just as the program form of the
F
command can pose a security risk
if the configuration file is poorly protected, so can the
M
delivery agent definition. Specifically, the
P=
equate
for a delivery agent (see
Section 30.4.9, P=
) can be modified to run a bogus program
that gives away
root
privilege. Consider the following
modification to the
local
delivery agent:

Here, local mail should be delivered with the
/bin/mail
program, but instead it is delivered with a bogus frontend,
/tmp/mail
. If
/tmp/mail
is
carefully crafted, users will never notice
that the mail has been diverted.
The
S
flag in the
F=
equate (see
Section 30.8.40, F=S
)
causes
sendmail
to
retain its default identity when executing the bogus
/tmp/mail
.
The
U=0
equate (see
Section 30.4.13, U=
) causes that default to become
the identity of
root
.

Delivery agent
P=
equates must be protected by protecting
the configuration file. As an additional precaution,
never
use relative pathnames in the
P=
equate.

The
F=S
and
U=0
are especially dangerous.
They should never appear in your configuration file unless
you have deliberately placed them there and are 100
percent certain of their effect.

When
sendmail
attempts to record its delivery agent statistics (see
Section 26.2.1, "The sendmail.st File"
),
it checks for the existence and write permissions
of the file specified by the
StatusFile
(
S
) option
(see
Section 34.8.66, StatusFile (S)
).
The
sendmail
program does not care where that file lives or what permissions it
has - only that it exists.

A security problem can arise if one is tempted to locate the statistics
file in a spool or temporary area. Consider the following location,
for example:

OS/usr/tmp/sendmail.st

Here the administrator sets the
StatusFile
(
S
) option to locate the statistics
file in the
/usr/tmp
directory.
The intention is that the file can be easily created by anyone who wishes
to gather statistics for a while, then removed.
Unfortunately, the
/usr/tmp
directory is usually world-writable.

Thus any unhappy or malicious user can bring the system to its knees:

%
cd /usr/tmp
%
ln -s /vmunix sendmail.st

Here,
sendmail
clobbers
the disk copy of the kernel. Nothing bad may happen at first,
[11]
but the machine will require manual intervention to boot in the future.
[12]
Clearly, precautions must be taken. For example, any file that
sendmail
writes to (such as the
StatusFile
(
S
) option
statistics file or the
aliases
database files) must be writable
only by
root
and live in a directory, every path component of which
is writable only by
root
.

[11] Programs that need kernel symbols, such as
ps
(1), will cease to work
or will produce garbage output.

[12] The savvy administrator can still boot off the network or from
a CD-ROM and quickly install a new kernel.