Sendmail | Maximum Mac OS X Security

Sendmail evolved from an early mail delivery package named, appropriately, delivermail, created in 1979 by Eric Allaman for use over ARPANET ”the predecessor of what we now know as the Internet. At the time, delivermail used the FTP protocol on top of NCP (Network Control Protocol). As ARPANET grew into the Internet, the need for enhanced mail services that ran over the new TCP/IP protocol suite became apparent. SMTP ”the Simple Mail Transport Protocol ”was developed to fill the lack of a dedicated mail transfer standard. With the addition of the DNS (Domain Name Service) in 1986, worldwide Internet email became a reality, and delivermail made the transition to sendmail. Initially released on BSD, sendmail finds itself right at home on Mac OS X (a BSD derivative). Throughout the 15+ years of its existence, sendmail has been continually enhanced, and, despite its popularity, is one of the most complicated server applications to understand and configure. For more information, read the "Brief History of Mail" at http://www.coruscant.demon.co.uk/mike/sendmail/history.html.

Mac OS X originally shipped with sendmail 8.10.2 for both its 10.0 and 10.1 releases. The latest Mac OS X, 10.2 (Jaguar) includes sendmail 8.12.2, which, while recent, is still not the most current version of the sendmail software. Since the 8.10.2 release, several important features have been added to the sendmail system, including improved SMTP AUTH support and security updates. To get an idea of why you'd want to keep your sendmail current, let's take a look at a few sendmail exploits, starting with the infamous Internet Worm.

The Morris Internet Worm

Although the version of sendmail that you have on your system is mostly secure, the history of the server software is far from squeaky clean. In the mid-80s sendmail served as one of the primary propagation methods for the infamous 80s Internet Worm ”or the Morris Worm, as named after its creator, Richard Morris. On November 2, 1988, Richard Morris unwitting released the most destructive Internet attack to date. Based on a 99-line program, the Morris Worm managed to do what today we can only hope is impossible ”take down the Internet. Attacking only Sun and VAX BSD-based systems, in less than a day the Internet Worm attacked popular system services and infested over 5000 of the best-connected machines in the country.

Sendmail provided one of the potential entry points for the worm. To quote Eric Allman, "The trap door resulted from two distinct 'features' that, although innocent by themselves , were deadly when combined (kind of like binary nerve gas)." The remote attacker took advantage of sendmail installations that were compiled with the DEBUG flag and the ability of sendmail to deliver messages to a system process rather than a user . Specifically, the attacking program would connect to the server, and provide a null sender and a subject line that would include the necessary keyboard commands to remove the preceding mail headers and insert the code to start a command interpreter. The body of the message contained the code necessary to compile and start the worm process again.

Although apparently not intended to be malicious, the worm itself contained bugs . The intended operation for the worm was to infect quietly and maintain a single harmless process running on each infected system. Unfortunately, the worm did not prevent itself from reinfecting an already infected machine. As a result, each infected machine started more and more worm processes, resulting in a rapid degradation of system services and eventual failure. For a complete history on the worm, the infestation, and the resulting network disaster, read Don Seely's "A Tour of the Worm" at http://world.std.com/~franl/worm.html.

NOTE

In reading the chronology of Don Seely's account of the worm, take notice of the length of time it took for sendmail to be patched after the exploit was discovered . Open Source has its benefits.

Recent Exploits

After weathering the Internet Worm, sendmail remained relatively quiet until the Internet (and thus email) became popular in the 90s. Over the years, numerous exploits have been found, and all have quickly been solved with an update. To give you an idea of what you're facing , here are a few of the bugs that have surfaced over the years.

Input Validation Bugs

Sendmail is often called from the command line to process and send email. To do so, it must be run SUID root. Unfortunately, numerous implementations of the server have suffered from poor input bounds checking, allowing local users to execute code as root on a number of operating systems. Several of the bugs are referenced here:

Linux . (CVE: CVE-2001-0653) http://online.securityfocus.com/advisories/3517
http://online.securityfocus.com/advisories/3513
IRIX . (CVE: CAN-2001-0714 and CAN-2001-0715) http://online.securityfocus.com/advisories/3666
NetBSD . http://online.securityfocus.com/advisories/3548

The Vacation Exploit

Although not directly related to a problem with sendmail, the Unix vacation utility, used almost exclusively with the sendmail server, triggered an inappropriate exploit through the MTA. "Vacation" was used to send an autoreply ("I'm on vacation!") to those who emailed your account. Rather than providing a sender address to sendmail within the body of its outgoing message, it used the command line to provide the address. The trouble with this approach is that vacation didn't check to see whether the command-line address truly was an email address. Malicious users could instead provide command-line arguments that would force sendmail to read an alternative configuration file and ultimately execute arbitrary code. A description of this exploit can be found at http://www. insecure .org/sploits/vacation_program_hole.html (CVE: CVE-1999-0057).

Unsafe Signal Handling

Used in a theoretical exploit, signal handling in sendmail could potentially lead to a race condition and effectively allow local users to execute arbitrary code as root, or cause a locally based DOS attack. Because this is not a remotely exploitable attack (and has never been seen implemented as an actual exploit), it should be of little concern to those running a dedicated mail server. Additionally, sendmail 8.12 eliminates the possibility of the attack taking place by removing the SUID sendmail requirement. To learn more about this potential exploit, read http://online.securityfocus.com/advisories/3328 (CVE: CAN-2001-1349).

Sendmail Exploit Resources

If you're interested in trying a few exploits on your Linux boxes (Linux distributions ship with a number of different sendmail versions), take a look at the following:

Phreak.org. http://www.phreak.org/archives/exploits/unix/sendmail-exploits/ ”A code collection of sendmail exploits, cataloged by version number.
PacketStormSecurity.nl . http://packetstormsecurity.nl/unix-exploits/sendmail-exploits/ ”Dozens of sendmail exploits and exploit descriptions.
Hacker Internet Security Services . http://www.hacker.com.br/exploits.php?id=3051 ”Exploits for the most recent versions of sendmail on the Linux platform.

As you can see, "stuff happens," but there are no reported OS X sendmail exploits at this time. Your primary concern should be getting sendmail set up safely with no chances of attack due to misconfiguration. In addition, you should learn how to update sendmail in case vulnerabilities do become an issue in the future. These topics will be the focus of the next several pages of the chapter. You must pay close attention to three areas, in particular:

File/Path Ownership and Permissions . Sendmail is picky (for good reason), about where you put your files and who has access to them.
Relay and Access control . Who can use your server, and when. Sendmail has a number of options to determine whether and when mail should be accepted and processed .
Local Users Access control . If you plan to run your server on a computer where users have access ( ssh / ftp /etc) to their accounts, you should limit their ability to intentionally (or unintentionally) compromise system security.

Top