sendmail, 4th Edition

The aliases File

The aliases file can easily be used to gain privileged (but not root) status if it is wrongly or carelessly administered. In addition to proper permissions and ownership, you should be aware of potentially harmful entries that you might have inherited from the vendor or previous administrators. For example, many vendors used to ship systems with a decode alias in the aliases file (this practice is becoming less common):

# you might wish to comment this out for security
decode:    |/usr/bin/uudecode

The intention is to provide an easy way for users to transfer binary files using mail. At the sending site, the user converts the binary to ASCII with uuencode(1), and then mails the result to the decode alias at the receiving site. That alias pipes the mail message through the /usr/bin/uudecode program, which converts the ASCII back into the original binary file.

The uudecode(1) program takes the name of the file to create from the file it is decoding. That information is in the begin line, used by uudecode. For example, here’s an attempt to use uudecode(1) to place a bogus queue file directly into the sendmail queue:

begin 777 /var/spool/mqueue/qfl0NFMs3g016812

Here, the begin tells uudecode to begin conversion. The 777 is the permissions to give to the file that will be created. That is followed by the full pathname of the file. If the queue directory were wrongly owned by daemon, any outsider could create a bogus queued message at your site.

Some versions of uudecode (such as the one with SunOS) will create set-user-id files. That is, a begin line such as the following can be used to create a set-user-id daemon shell in /tmp:

begin 4777 /tmp/sh

The decode alias should be removed from all aliases files. Similarly, every alias that executes a program—that you did not place there yourself and check completely—should be questioned and probably removed.