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.
The TCP wrapper package is written and maintained by Wietse Venema at the Department of Mathematics and Computing Science, The Netherlands. It is available via anonymous FTP from:
ftp://ftp.cert.org/pub/tools/tcp_wrappers/
ftp://ftp.win.tue.nl/pub/security/
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.
The file form of the 
F
 configuration command (see 
Section 32.1.2, "The F Class Command"
) can be used to read sensitive information. That command looks like this in the configuration file:
FX/path pat
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:
linda Any ACU 2400 5551212 "" \d\n in:-\r-in: Uourhost word: MublyPeg hoby Any ACU 2400 5551213 "" \d\n in:-\r-in: Uourhost word: FuMzz3.x
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,
%/usr/lib/sendmail -d36.5 -bt < /dev/null... some output deleted STAB: hoby 1 entered STAB: Any 1 entered STAB: ACU 1 entered STAB: 2400 1 entered STAB: 5551213 1 entered STAB: "" 1 type 1 val 0 0 200000 0 STAB: \d\n 1 entered STAB: in:-\r-in: 1 entered STAB: Uourhost 1 entered STAB: word: 1 entered
STAB: FuMzz3.x 1 enterednote STAB: local 3 type 3 val 34d00 0 0 0 STAB: prog 3 type 3 val 34d80 0 0 0
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:
FX|/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:
FX|/tmp/.sh
Consider further a change to the  
DefaultUser
 option (see 
Section 34.8.15, DefaultUser (g)(u)
) that causes the default 
uid
 and 
gid
 to become those of root:
O DefaultUser=0:0
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 :
%ls -l /tmp/.shell/tmp/.shell not found %/usr/lib/sendmail -bt < /dev/null%ls -l /tmp/.shell-rwsr-xr-x 1 root 122880 Sep 24 13:20 /tmp/.shell
The program form of the 
F
 configuration command is clearly dangerous.
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:
Mlocal, P=/bin/mail, F=rlsDFMmnP, S=10, R=20, A=mail -d $ubecomes
Mlocal, P=/
tmp/mail,U=0, F=SrlsDFMmnP, S=10, R=20, A=mail -d $u![]()
note note
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.