S 5.19 Use of the sendmail security mechanisms

Initiation responsibility: Administrator

Implementation responsibility: Administrator

Since mail transmission would appear to be application most frequently used in networks, the pertinent processes are of particular importance and one of the most common targets in a system. Another aspect is the fact that these processes have often set the suid bit and belong to a privileged user (e.g. root or bin). For instance, an error in sendmail was one of the reasons for the propagation of the Internet worm.

• As regards the starting of sendmail, many options can be listed which would lead to security problems if they were run with root rights. If sendmail can be called up by any user, then a check should be made to see whether it disregards the set suid bit when being started with any of these options and runs with the user's UID. In order to avoid security problems, the administrator should ensure that sendmail can be started only with the following options with the set suid root bit by non-privileged users: 7, b, C, d, e, E, i, j, L, m, o, p, r, s and v.
• Security shortcomings have been discovered in the sendmail program in the past. Therefore, the most recent program version must always be used. Information on the current versions is provided by the agencies listed in S 2.35 Obtaining information on security weaknesses of the system, such as BSI, CERT, DFN-CERT.
• It should not be possible to run the sendmail process in the debug mode, as it would then be possible to obtain root rights. This can be tested by entering the command
  
  telnet localhost 25
  
  where localhost can be the name of the computer to be checked and 25 the port number for addressing the sendmail process. The computer or the sendmail process will then respond with the message
  
  Trying 123.45.67.8... Connected to xxx.yy.de. Escape character is '^]'. 220 xxx Sendmail 4.1/SMI-4.1 ready at Wed, 13 Apr 94 10:04:43 +0200
  
  
  
  
  If you now enter the command debug, showq or, in very old versions wizard, the process should deny this with the message
  
  500 Command unrecognized
  
  . You can then exit the connection with the quit command.
• The vrfy and expn commands must not be available, since they give the matching log-in name for a mail name, and the pertinent password might then be found out by trial. In version 8 of sendmail these commands can be disabled on starting, e.g. by the p (privacy) option. As described above, the availability of these commands can be verified, e.g. by entering the vrfy useralias command.
• The configuration file sendmail.cf should belong to root, and read and write access should also be confined to root. The same goes for the higher-level directories since it would otherwise be possible, by simply renaming these directories, to generate a new sendmail.cf file.
• The identification of executable programs or files as valid addresses for a recipient or sender must be prevented by the configuration of sendmail.cf or restricted to certain safe programs and files by appropriate safeguards.
• The F command (e.g. FX/path [^#]), which serves to define classes, should only be used in the configuration file (sendmail.cf) to read files, which can be read system-wide, as security-related information from protected files might become generally available otherwise. The program format of the F command (e.g. FX|/tmp/prg) should not be used!
• When defining delivery agents (e.g. Mlocal) only absolute paths may be indicated (e.g. P=/bin/mail). Moreover, the S flag (suid) should only be set when any security problems that may be associated with it have been resolved.
• Any file to which sendmail could write, e.g. sendmail.st for statistics, should only be write accessible to root and should only be listed in directories belonging to root. The same goes for files used by sendmail, e.g. :include: in mailing lists.
• Privileged users like bin or root should not have a .forward file. If the user or group write-access rights for this file are set incorrectly or if a user manages to get into a privileged group, this user can generate a shell with the privileged user ID.
  
  In the case of normal users, only the owner should have write access to the .forward file, and this must be located in a directory belonging to the owner.
  
  If system-wide write access to a home directory needs to be available, e.g. uucp, the creation of a harmful .forward file can be prevented in the following manner: A directory with the name .forward, the rights 000 and the owner root must be created and, under this directory, a file also having the rights 000 and the owner root must be created so that no one else but root can modify or delete these files. In this case, the home directory of uucp should also belong to root and be provided with the sticky bit (t). A similar approach is also recommended for other configuration files (e.g. .login, .cshrc) in directories with system-wide write access.
• Any executable program, including uudecode in particular, should be removed from the alias file. Moreover, the alias file and the associated database should belong to root, and only root should have write access to them.
• It must be borne in mind that any mail received might be corrupt. Corruption can occur either in the mail queue or through log-in on port 25. The first situation can be avoided if the mail queue directory belongs to root and has the rights 0700. The queue files should have the rights 0600. The modification of a mail during its transmission cannot be avoided. Therefore, users must be made aware of the fact that, for instance, a mail message from root requesting them to alter their passwords may be faked.

Review questions:

• Is it ensured that sendmail can only be started with the set suid root bit and using the permissible options?
• Is the operation of the sendmail process in the debug mode prevented?
• Is the execution of the VRFY and EXPN commands prevented for sendmail?
• Are the authorisations for relevant files (e.g. sendmail.cf, sendmail.st, alias, queue, :include: in mailing lists) and the higher-level directories reduced to the minimum necessary?
• When defining delivery agents (e.g. Mlocal), are only absolute paths indicated (e.g. P=/bin/mail)?
• Are the forward files only available for non-privileged users?