Known Holes in sendmail July 26, 1995 This list of sendmail security holes documents the well-known holes. I intend to expand and update it over time. MUCH OF THIS INFORMATION COMES FROM: The usenet comp.mail.sendmail faq The Costales-Allman-Rickert sendmail book by O'Reilly Cert RFCs And just plain gossip and experience. I NEEDED A STARTING POINT, AND AM GRATEFUL FOR THE CONTRIBUTERS LISTED ABOVE. IF YOU SEE AN ERROR IN THIS DOCUMENT, IT IS MOST LIKELY MINE. CHARACTERISTICS --------------- When configured properly (see Command-Line Switch Pitfalls) sendmail starts to run as root, continuing as root until it delivers mail. It then changes it's identity to that of an ordinary user. When sndmail reads it's configuration file, it generally does so while it is still root. Command Line Switch Pitfalls ---------------------------- -C Configuration file location Make sure it is protected as noted below. -d Enter debugging mode Make sure sendmail is configured properly. I don't know of any way to disallow invocation by users. -h Initial hop count Normally 0; some list processors set it higher to avoid propigating errors. Setting it very high can force all mail to bounce. The max hop count is compiled in with all versions but 8, which sets it in a configuration file with the h option. It cannot, in either case, be set to a negative number. Configuration File Dangers -------------------------- THE F COMMAND - FILE FORM ------------------------- USAGE: Read class macro entries from file. PROBLEMS: Misunderstanding scanf patterns can allow experienced and unscrupulous users to be able to monitor the contents of files, including passwords. SOLUTIONS: Avoid using the F command to read a file that is not already publicly readable. Avoid adding a command to the configuration file by copying and modifying another command. The F command is an excellent example of a situation where taking a shortcut (not fully understanding the command) results in an inappropriate application of a legitimate command. THE F COMMAND - PROGRAM FORM ---------------------------- USAGE: Allows sendmail to specify a program to run. PROBLEMS: A somewhat obvious risk, especially where several administrators share access to a configuration file to delegate the postmaster's duties. SOLUTIONS: The program form of the F configuration has been removed from version 8 of sendmail. Always make sure you are using (within reason) the latest version of sendmail. The sendmail configuration file should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. THE F FLAG - RETAINS ROOT ------------------------- USAGE: Causes sendmail to remain root after delivering mail. PROBLEMS: Sendmail can be tricked into running inappropriate programs, shells or scripts. SOLUTIONS: Do not ever use the F=S delivery agent flag unless it is absolutely necessary and you know the exact ramifications. THE P FLAG - EQUATES ONE PROGRAM WITH ANOTHER --------------------------------------------- USAGE: Substitutes an optional delivery agent. PROBLEMS: Can be used to substitute a bogus delivery agent, potentially copying- or even redirecting- all mail. SOLUTIONS: Never use relative pathnames with the P= equate. The sendmail configuration file should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. THE S OPTION - CHECKS FOR EXISTENCE AND WRITABILITY OF A STATISTICS FILE ------------------------------------------------------------------------ USAGE: Determines existance and writability of a statistics file. PROBLEMS: Does not check the location or permissions of that file. Placing this file in a world-writable area allows people to periodically gather statistics and remove the file to save disk space. The obvious ramifications are legion. A (perhaps less obvious) abuse is the ability to create a soft link to the kernel itself- and destroy it. A reboot, of course, will fail, and the administrator will have to boot from alternate media, such as a CD-ROM, or the network. SOLUTIONS: Programs that require kernel symbols will cease to work or produce garbage output. Watch out for unusual behavior. Any file that sendmail writes to, including statistics files and alias databases, should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. Sendmail Internal Dangers - Not Changable by Configuration Files ---------------------------------------------------------------- MAILING LISTS - BE CAREFUL WHO OWNS THEM ---------------------------------------- USAGE: Sendmail doesn't always run as root. Sometimes it changes it's identity to a user when delivering mail. If a mailing list is owned by root sendmail has the same privilages as it does when running as root. If a list is owned by a normally-privilaged user no special privilages are granted. PROBLEMS: When a list is owned by a semi-privilaged user (see below) an ordinary user in that group can create an suid shell that allows any ordinary user in the group to become the semi-privilaged owner. SOLUTIONS: Mailing lists should live in a directory where every path component of which is writable only by root. The list itself should only be writable by the owner. Mailing lists should not be owned by semi-privilaged users. Sendmail's [u] and [g] (user and group) options for root are, by default, [daemon]. They should be set to [nobody] and [nogroup] for the instances when sendmail processes a list owned by root. THE ALIAS FILE - CHECK FOR HARMFUL ENTRIES ------------------------------------------ USAGE: Sets aliases for users, groups, lists, etc. An alias file is practiaclly an indispensable tool, but it can harbor dangers other than invalid or misdirected users. PROBLEMS: It can also contain entries that allow a program to be run, such as decode for uuen/decode, enabling transfer of binary files via mail. SOLUTIONS: Vendors generally no longer ship with a decode alias. But you should check for it's presence. Any other programs referenced in the alias file that you did not put there yourself, fully understand, and verify (tripwire is verification- checksums and date/time stamps are not) should be subject to careful scrutiny. The alias file- and it's corrosponding database files - should never be writable by anyone other than root. They should also live in a directory where every path component is owned and writable only by root. Operating System Dangers ------------------------ SEMI-PRIVILAGED USERS - BE CAREFUL OF WHERE THEY STORE FILES ------------------------------------------------------------ USAGE: Semi-privilaged users, such as bin, have authority to run programs without having all the privilages of root. PROBLEMS: Semi-privilaged users often own the directories where root-owned programs reside. Unix pays less attention to semi-privilaged users than it does to root, possibly allowing them to be compromised more easily. For example, [root] is mapped to [nobody] over NFS, but [bin] remains [bin]. This allows bin, if compromised, to rename, redirect or substitute programs. SOLUTIONS: All system directories and files (except possibly suid and sgid files) should always be owned and writable only by root. Group ownership of system files is dangerous. Any file owned by root- not just sendmail files- should never be writable by anyone other than root. It should also live in a directory where every path component is owned and writable only by root. FORWARD FILES - A CLASSIC DANGER -------------------------------- USAGE: The ~/.forward file redirects incoming mail for users with accounts on multiple machines. PROBLEMS: It is common knowledge that the .forward file can be linked (via a soft link) to files such as the shadow password file, whose contents can be at least partially transmitted by a manual telnet to port 25 and an expansion of the file name. This has been solved in most operating systems several revisions ago. Other implications, as outlined above, remain if the owner of a forward file is a semi-privilaged user, or if a normally-privilaged user's .forward file is group writable. SOLUTIONS: Upgrade regularly to the latest version of your operating system. Use the latest version of sendmail (8.12.6?). Semi-privilaged users (like bin) and root should not have .forward files at all. They should forward mail via the aliases file. Users' ~/.forward files should not be group-writable; they should be writable only by the owner. User home directories must live in a directory owned and writable only by root. User directories themselves must be owned and writable only by the user. In the case of programs like uucp, which must have world- writable home directories for the software to work properly, create a directory called .forward. Protect it by creating at least one dummy file in it, changing owner of the directory and file to root and set the permissions of both to 000. Change the file's sticky bit with chmod +t so it cannot be removed by anyone but the owner. Route mail for uucp to a real user via an alias. Follow this same procedure for all critical dot files in a world-writable directory, such as .rhosts, .login, .cshrc and .kshrc, .profile and .logout. FINAL CONSIDERATIONS: --------------------- Monitor your system logs regularly, frequently and carefully. Use tripwire. Consider using procmail for your local delivery agent. Many people believe it is the most secure local delivery agent. Use smap so some analysis and filtering is done. Smap also makes attacks mounted by direct user telnet to port 25 difficult. Make sure your installed version of sendmail has *not* been compiled with the smtp debug option enabled- the hole that allowed Morris's Internet Worm. You do not need to turn off all debugging, just SMTP debugging. To make sure it is off, telnet to port 25 and invoke the debug command. The proper response should be [500 Command unrecognized]. The response indicating that smtp debugging is enabled is [200 debug set]. Get a new copy from your vendor or recompile with SMTPDEBUG undefined. Make sure logging is enabled by setting the L option to nonzero. Many abnormal situations, like the example above, will be recorded. Logging is not just for security however; it is useful for problem determination. Consider whether you want to install the finger daemon. It reveals logon names, from which probers can attempt to guess passwords. Use a passwd program that does not allow trivial passwords. Make sure passwords expire regularly. The latest versions of V8 and IDA sendmail log verify attempts, whether or not they fail (previously only failures were logged) so attempted expansions of mailing lists will be noted. This is only useful if you use the latest version and enable logging. Version 8 allows verify and expand services to be selectively accepted or rejected. Use sendmail with the P (privacy) option enabled. It's use does not change sendmail's state to root, and it cannot be manipulated to make sendmail less secure- only more secure. But do note that some of it's response messages might might be considered rude.