Digg this story   Add to del.icio.us  
Return to sender?
Jon Lasser, 2001-09-05

The new Sendmail hole sparks flashbacks to the program's insecure past. Is it time to switch to an alternative?

The recent Sendmail local root exploit must have supporters of alternative SMTP servers chuckling. I won't be surprised if this exploit is cited by many as another reason to switch from Sendmail to Postfix or qmail. I don't buy those arguments, but there are reasons for some sites to consider an alternative.

The new hole is straightforward enough: improper parameters can be passed by local users to the debug command, which can result in elevated privileges. This is the first serious security flaw in Sendmail since 1997, according to reports, and as a local root exploit it is to my mind a member of the third most serious class of exploits. I consider both remote root and remote user exploits to be more serious, because they subvert authentication, while local root exploits only defeat limits on authorization.

The problem is somewhat reminiscent of the Sendmail exploit used by the Morris worm, in that it exploits Sendmail's debug mode. (Incidentally, my last column incorrectly identified that worm as the first: I had intended to say only that it was the first Internet worm. Researchers at Xerox PARC had experimented with worms long before Robert T. Morris wrote his.)

Prior to Sendmail 8.8.7's release in October 1997, a near constant stream of security advisories earned the program a very poor security reputation. In response, several alternative mailer projects sprung up. Dan Bernstein began the qmail project in late 1995, and Wietse Venema's VMail project, which later became Postfix, was made available in mid-1997.

Both of these projects reject Sendmail's approach of a monolithic privileged application that encompasses all functions of mail transport and delivery. Instead, these mail servers are made up of a larger number of small applications, each of which handles a single part of the process.

In theory, the security benefits of such an architecture are substantial, and neither of Sendmail's major competitors has experienced a serious security hole. But neither has Sendmail since 1998, when its developers did some serious code audits for the 8.8.x cycle of releases.

Since then, Sendmail has occasionally shown off security problems in the underlying operating systems, but has had no serious exploits of its own.

The current Sendmail hole exists only in the 8.10.x and 8.11.x versions of the software, which perhaps indicates a need for another code audit, but also suggests that the previous audit must have been fairly effective.

Software Diversity
And there are a trade-offs in embracing a Sendmail replacement. Both qmail and Postfix give up large amounts of flexibility regarding address rewriting. The good news is that few sites need any of that flexibility, and those that do could find happiness with a hybrid solution: use one of the replacement packages as the registered mail server for their site, but pass off all mail onto a Sendmail box not directly accessible from elsewhere.

Frankly, though, given Sendmail's recent security record, this seems unnecessary. It may be that the excellent security track record of both qmail and Postfix is a function of their newness. After all, if only one Sendmail hole has turned up in the last four years, and if Sendmail is still riddled with insecurities, as adherents of its various alternatives claim, how long does it take to find these bugs?

Dumping Sendmail for security reasons reflects faith in a theoretically-better, but fundamentally less proven, architecture.

Of course, there are other reasons to consider an alternate SMTP server implementation, including ease of configuration and maintenance, and improved performance when dealing with bulk e-mail.

And there is the crucial issue of software diversity.

Just as the dominance of Microsoft Outlook as a mail client has permitted the spread of email worms to an almost unimaginably large user base, the thorough dominance of any single software package or operating system threatens the stability of the Internet: a serious flaw in that one program would bring the Internet to its knees, either through intentional abuse, or through unforeseen side-effects of some sort causing a cascading failure. (The former is substantially more likely, of course.) Using an alternate mail server encourages software diversity and thus helps to protect the entire Internet.

Of the alternatives, Postfix would be my choice for a Sendmail replacement. The author of qmail has a history of engaging in needless flame wars, and exhibits a cavalier disregard for Internet standards of which he does not approve. I believe this makes for a poor developer environment. In addition, the license for qmail is rather non-standard. Technically, the quality of the software appears to be good (though it has been known to bring down other systems' mail servers in an attempt to deliver mail more quickly), but the personalities involved lead me to favor Postfix.

Postfix's primary author, Wietse Venema, has a long history of cooperation in the Internet community, and his TCP Wrappers have become a standard means of access control across the Unix and Linux universe. He is widely regarded as a security expert, and his other software has a good track record. Postfix is much more strict about RFC compliance than qmail, it does not display pathological behavior when a downed mail server comes back onto the network, and it appears to be equally secure. If you decide to replace Sendmail, take a good look at Postfix.

SecurityFocus columnist Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.
    Digg this story   Add to del.icio.us  
Comments Mode:


Privacy Statement
Copyright 2010, SecurityFocus