IT Baseline Protection Manual S 5.19 Use of the sendmail security mechanisms
S 5.19 Use of the sendmail security mechanisms
Initiation responsibility: IT Security Management, Administrators
Implementation responsibility: Administrators
Since mail transmission would appear to be the application most frequently used in networks, the pertinent processes are of particular importance and are one of the most common targets in a system. A further aspect is the fact that these processes often have set the suid bit and belong to a privileged user (e.g. root or bin). For instance, a fault 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 privileges. Therefore, if sendmail can be called up by any user, a check should be made to see whether, when being started with any of these options, it disregards the set suid bit and is run 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.
On account of the security shortcomings of the sendmail programme which have been discovered in the past, the most recent programme version must always be used. Information on the current versions is provided by the agencies listed under S 2.35 Obtaining information on security flaws of the system, such as BSI, CERT, DFN-CERT.
It should not be allowed to run the sendmail process in the debug mode as in that case it would be possible to obtain root privileges. 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
If you now enter the command debug, showg or, for very old versions, wizard, the process should repudiate this with
500 Command unrecognised
You can then exit with the quit command.
The commands vrfy and expn must not be available since they give the matching log-in name for a mail name so that the pertinent password might then be found out by trial. For sendmail Version 8, these commands can be disabled during starting, e.g. by the p option ( privacy). As described under the preceding point, 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, otherwise, by simply renaming these directories, it is possible to generate a new sendmail.cf file.
Identification of executable programmes or of files as valid addresses for a recipient or sender must be prevented by the configuration of sendmail.cf or, by appropriate measures, be confined to certain safe programmes and files.
The F command (that is, for instance, FX/path [^#]) which serves to define classes should be used in the configuration file ( sendmail.cf) only to read files which anyhow can be read system-wide, as, otherwise, relevant security information from protected files might become generally available. The programme format of the F command (e.g. FXFehler! Es wurde kein Textmarkenname vergeben./tmp/prg) should not be used!
For definition of the delivery agent (e.g. Mlocal), only absolute paths may be indicated (e.g. P=/bin/mail). Also the S ( suid) flag should be set only when any security problems involved have been resolved.
For any file to which sendmail could write, e.g. sendmail.st for statistics, only root should have write access, and it should also only be listed in the directories belonging to root. The same goes for files used by sendmail, such as :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, he 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.
In case asystem-wide write access to a home directory needs to be available, e.g. uucp, creation of a deleterious .forward file can be prevented in the following way: A directory with the name.forward, the rights 000 and the owner root and, under this directory, a file also having the rights 000 and the owner root must be created so that nobody 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 recommended also for other configuration files (e.g..login,.cshrc) in directories which can system-wide be written to.
Any executable programme, including uudecode in particular, should be removed from the alias file. Moreover, the alias file and the pertinent database should belong to root, and only root should have write access to them.
It must be borne in mind that any received mail 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 rights0700. The queue files should have the right0600. Modification of mail during its transport cannot be avoided so that 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
